systemdタイマーを使用してownCloudのバックグラウンドジョブを確実に実行する

ownCloudの管理ページでバックグラウンドジョブが実行されていないと表示される場合、キューに入れられたクリーンアップやその他のスケジュールされた作業は、誰かがサイトにアクセスするまで遅延する可能性があります。systemdで管理されているLinuxサーバーでは、ownCloudのバックグラウンドジョブモードをCronに設定し、タイマーを使用してocc system:cronWebサーバーアカウントで実行してください。現在のownCloud Serverのドキュメントでは、定期的なバックグラウンド作業にはシステムcronの使用を推奨しており、systemdタイマーもコマンドをスケジュールする別の方法として特に言及しています。

このガイドは、Linuxホストに直接インストールされたownCloud Server Classicを対象としています。アーキテクチャが異なるownCloud Infinite Scaleや、内部で既にcronを実行している公式のownCloud Dockerイメージには適用されません。Dockerの場合は、2つ目のホストタイマーを作成するのではなく、イメージのドキュメントに記載されている設定に従ってください。最新のownCloud Serverバックグラウンドジョブのドキュメントを参照してください。

スケジュールを変更する前にコマンドを確認してください

systemdサービスは実行するコマンドを定義し、タイマーはそのサービスを定期的に起動します。まず、ownCloudのインストールパスとHTTPサーバーアカウントを確認してください。以下の例では、DebianとUbuntuで一般的な`@example.com`と`@example.com`を使用しています/var/www/owncloud。他のLinuxディストリビューションでは、 `@example.com`、`@example.com` 、または別のアカウントwww-dataを使用する場合があります。wwwrunapache

コマンドの不具合とスケジュールの不具合を区別するために、そのアカウントでownCloudコマンドを手動で実行してください。

sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ system:cron

PHP 実行ファイルとパスをoccサーバーに合わせて変更してください。ownCloud ではsystem:cron、バックグラウンド ジョブには の使用を推奨しています。スケジュールに関する古いガイドは、cron.php以前の動作を参照している可能性があります。現在のコマンドは成功メッセージを表示せずに終了する場合がありますので、echo $?直後に で終了ステータスを確認してください。0は、コマンドが正常に終了したことを意味します。エラーが返された場合は、まずパス、PHP CLI のインストール、権限、データベース接続、または ownCloud のエラーを修正してください。このチェックをスキップすると、タイマーは同じ失敗したコマンドを繰り返し実行します。

ownCloudをCronモードに設定する

ownCloudの管理者設定で、バックグラウンドジョブまたはCronセクションを開き、Cronを選択します。インストールディレクトリからスケジューラを設定することもできます。

cd /var/www/owncloud
sudo -E -u www-data php occ background:cron

これにより Cron モードが選択され、スケジュールされたコマンドはそのままになりますocc system:cron。ownCloud のマニュアルによると、このコマンドは管理ページで Cron を選択するのと同等です。AJAX はページへのアクセスに依存し、閑散期には処理が滞る可能性があるため、ジョブを確実に処理する必要があるサーバーには Cron が推奨されます。小規模な個人インスタンスでは AJAX の方が簡単かもしれませんが、予測可能性は低くなります。

systemdサービスとタイマーを作成する

/etc/systemd/system/owncloudcron.service実際のHTTPアカウントとownCloudパスを使用して作成してください。

[Unit]
Description=ownCloud background jobs

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/var/www/owncloud
ExecStart=/usr/bin/php -f /var/www/owncloud/occ system:cron

Type=oneshotコマンドが完了するまで実行され、その後終了するようにsystemdに指示します。PHPのフルパスを指定することで、PATHシステムサービスで利用可能な機能が限られていることへの依存を回避できます。作業ディレクトリは、ownCloudが相対パスを解決するのに役立ちます。サービスアカウントは、ownCloudファイルおよびデータアクセスの所有者と一致させてください。root権限でジョブを実行しないでください。

次に、以下を作成します/etc/systemd/system/owncloudcron.timer。

[Unit]
Description=Run ownCloud background jobs every 15 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=15min
Unit=owncloudcron.service

[Install]
WantedBy=timers.target

ownCloudのマニュアルでは、標準的なcronの例として15分間隔を推奨しており、代替スケジューラとしてsystemdタイマーも認めています。このタイマーは起動後5分で開始し、サービスがアクティブ化されてから15分後に次の実行をスケジュールします。ワークロードで別の間隔が必要な場合は、OnUnitActiveSec慎重に変更し、各実行の完了に必要な時間を考慮してください。同じコマンドに対して別のcrontabエントリを設定することは避けてください。重複したスケジューラによって冗長な実行が開始され、トラブルシューティングが困難になる可能性があります。

systemdにユニット定義を再読み込みするように指示し、タイマーを有効にして開始します。

sudo systemctl daemon-reload
sudo systemctl enable --now owncloudcron.timer

daemon-reloadユニットファイルの作成または編集後に必要です。タイマーを有効にすると、以降の起動時に自動的に開始されます。--now現在のセッションで開始します。サービスだけでなく、タイマーユニットも有効にしてください。

実行がスキップされた、または失敗した理由を調べる

タイマーが有効になっているかどうか、そして次回いつ実行されるかを確認してください。

systemctl is-enabled owncloudcron.timer
systemctl list-timers --all owncloudcron.timer
systemctl status owncloudcron.timer

有効になっているタイマーは、タイマー一覧に次の起動予定とともに表示されるはずです。表示されない場合は、ユニットファイル名を確認し、systemd をリロードして、タイマーを再度有効にしてください。タイマーが実行中と表示されているにもかかわらず、ownCloud の動作が遅延している場合は、サービスとそのログを確認してください。

systemctl status owncloudcron.service
sudo journalctl -u owncloudcron.service --since today

パスが間違っている、データディレクトリにアクセスできない、PHP拡張機能が見つからない、またはデータベースエラーがないか確認してください。サービスファイル内の正確なコマンドを手動でテストして、環境をできるだけ忠実に再現してください。また、 Nextcloudの例をコピーして呼び出すのではなく、www-dataownCloudコマンドを使用していることを確認してください。occ system:croncron.php

ownCloudがジョブを処理していることを確認してください。

タイマーが1回または2回作動した後、サービスが正常に完了し、タイマーに次の起動がスケジュールされていることを確認してください。次に、ownCloud管理者ページでバックグラウンドジョブの状態を確認します。表示される最終実行時刻が進み、古いCron警告が消えるはずです。systemdが成功を報告しているにもかかわらず警告が残る場合は、ownCloudのアプリケーションログを調べ、Web UIがコマンドラインインストールで使用されているものと同じインスタンスとデータベースに接続されているかどうかを確認してください。

公式のownCloudコンテナの場合、コンテナの内部スケジューラを意図的に無効にし、ownCloudの最新のコンテナドキュメントでその構成がサポートされている場合を除き、これらのホストユニットをインストールしないでください。ここでの設定は、systemd上の従来のownCloud向けのホストレベルのソリューションです。サービス名、パス、PHPバージョン、およびコンテナの動作は、デプロイメントによって異なります。