ownCloudのCronジョブが実行されない問題を解決する：信頼性の高いsystemdタイマーを設定する

ownCloudの管理ページを開くと、バックグラウンドジョブが最近実行されていない、またはクリーンアップ、アクティビティ、外部ストレージ、その他のキューに入れられたタスクが遅れているように見えることがあります。よくある反応は、cron.phpcrontabエントリを編集または追加することです。現在のownCloud Serverのドキュメントでは、これは最適な出発点ではありません。ownCloudは、Cronバックグラウンドモードとocc system:cronコマンドの使用を推奨しています。Linuxホストでは、従来のcrontabの代わりにsystemdタイマーを使用してスケジューリングレイヤーを提供できます。

このガイドでは、ownCloud が などのパスに配置されているパッケージまたはベアメタルスタイルのインストールに焦点を当てています/var/www/owncloud。ownCloud の公式 Docker イメージを使用する場合は、ホストタイマーを作成する前に停止してください。ownCloud のドキュメントには、イメージが や などの変数によって制御される cron を内部的に構成することが記載されていますOWNCLOUD_CROND_ENABLED。OWNCLOUD_CROND_SCHEDULE最新のownCloud バックグラウンド ジョブのドキュメントを参照してください。

何が検証済みで、何がサーバーに依存し、何がまだ確認が必要なのか

• 検証済み： ownCloudは、信頼性の高いバックグラウンド実行にはAJAXではなくCronを推奨しており、occ system:cronキューに入れられたバックグラウンドジョブを実行するためのコマンドとしてドキュメント化しています。
• インストール方法によって異なります。ownCloudディレクトリ、PHPバイナリ、Webサーバーアカウント、PHP環境、そしてパッケージインストール、コンテナ、アプライアンス、カスタムデプロイメントのいずれを実行しているかによって変わります。
• 一般的なガイドでは、現在のジョブが失敗した理由を特定することはできません。スケジューラの問題である可能性もありますが、権限の問題、パスの誤り、PHP CLIの設定の違い、データベース接続の問題、ファイルのロック、またはアプリケーションレベルのバックグラウンドジョブの失敗などが原因である可能性もあります。

対処法：タイマーに使用するアカウントと同じアカウントで、ownCloudのコマンドが手動で正常に動作することが確認できるまで、タイマーを作成しないでください。

ステップ1：Cronモードを確認し、ownCloudを手動でテストする

一般的なApache/Debianスタイルのインストールでは、Webユーザーは ですwww-data。環境が異なる場合は、ユーザー名とパスの両方を置き換えてください。

sudo -u www-data /var/www/owncloud/occ background:cron
sudo -u www-data /var/www/owncloud/occ system:cron

最初のコマンドは、ownCloudのCronバックグラウンドジョブモードを選択します。2番目のコマンドは、キューに登録されたバックグラウンドジョブを実際に実行します。ownCloudのoccコマンドのドキュメントにはsystem:cron、このコマンドはスケジュール実行を目的としており、非対話型スケジューラでは進捗状況の出力は有効にすべきではないと記載されています。

よくある誤解： ownCloudの「Cronモード」は、cron必ずしもデーモンを使用する必要があるという意味ではありません。ownCloudがバックグラウンドジョブランナーを呼び出すために外部スケジューラを必要とするという意味です。systemdタイマーをそのスケジューラとして使用できます。

対処法：手動コマンドが失敗した場合は、まずそのエラーを修正してください。タイマーは、スケジュールに基づいて同じ失敗を繰り返します。

ステップ2：正しいPHPとownCloudのパスを見つける

インストールによってはocc直接実行可能になる場合もあれば、PHP CLIバイナリで起動した方が動作が予測しやすい場合もあります。両方を確認してください。

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

ownCloudのドキュメントでは、スケジュールされたジョブがPHPを見つける必要があることを明示的に警告しており、そのためcronの例では完全なパスを示しています。これはsystemd環境でも同様に重要です。なぜなら、サービスは対話型シェル環境ではなく、制御された環境で実行されるからです。

対処方法：/usr/bin/php残りの例の、、、/var/www/owncloudおよびを、www-dataご使用のホストで正常に動作した値に置き換えてください。

ステップ3：ワンショットのsystemdサービスを作成する

作成する/etc/systemd/system/owncloud-cron.service：

[Unit]
Description=Run ownCloud background jobs
After=network.target

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

通常、サービス専用のセクションは必要ありません[Install]。タイマーがサービスを起動するからです。サービスをこのように設定しておくと、Type=oneshotライフサイクルも分かりやすくなります。サービスが起動し、コマンドを一度実行し、終了して、再び非アクティブになります。

よくある誤解：非アクティブなワンショットサービスは自動的に停止するわけではありません。正常に実行されたワンショットサービスは、RemainAfterExit=yes通常、非アクティブになります。

対策：サービスの成功は、終了コードとログに基づいて判断し、サービスが「稼働し続ける」ことを期待してはいけません。

ステップ4：systemdタイマーを作成する

作成する/etc/systemd/system/owncloud-cron.timer：

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

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=owncloud-cron.service

[Install]
WantedBy=timers.target

ownCloudのホストcronのドキュメントでは、15分間隔のスケジュールを推奨しています。上記のタイマーもその間隔に従います。systemdはマシンが再び利用可能になった後にカレンダーの起動をトリガーできるため、タイマーPersistent=trueと併用すると便利ですOnCalendar。ただし、正確な動作はsystemdのバージョンとマシンのダウン時間によって異なります。

対処法：意図的に異なる間隔が必要な場合は、他のサーバーから値をコピーするのではなく、意図的に変更してください。実行頻度が高すぎるとバックグラウンド負荷が増加し、低すぎるとキューに登録された処理が遅延する可能性があります。

ステップ5：systemdをリロードしてタイマーを有効にする

sudo systemctl daemon-reload
sudo systemctl enable --now owncloud-cron.timer
sudo systemctl status owncloud-cron.timer

daemon-reloadsystemdにユニットファイルを再読み込みさせます。enable --nowこれにより、今後の起動のためのタイマーが有効になり、同時に起動も即座に開始されます。

対処法：タイマーがアクティブでない場合は、systemctl status owncloud-cron.timerownCloudの設定を再度変更する前に確認してください。

ステップ6：次のタイマーと前のタイマーの実行を確認する

systemctl list-timers owncloud-cron.timer
systemctl list-timers --all | grep owncloud-cron

list-timersこれは、systemdが次回の起動をスケジュールしたことを確認し、タイマーが最後に作動した日時を確認する最も簡単な方法です。これにより、「タイマーが一度も作動しなかった」場合と「タイマーは作動したが、ownCloudがサービス内で失敗した」場合を区別できます。

対処方法： NEXTが表示されない場合、またはタイマーがリストにない場合は、タイマーのファイル名、[Install]セクション、およびユニットが有効になっているかどうかを再確認してください。

ステップ7：タイマーだけでなく、サービスジャーナルも確認してください。

systemd は、意図的に別の場所にリダイレクトしない限り、サービスの出力をジャーナルに記録します。公式のjournalctl ドキュメントには、systemd ユニットによるジャーナルエントリのフィルタリング方法が記載されています。

sudo journalctl -u owncloud-cron.service --since today
sudo journalctl -u owncloud-cron.service -n 100 --no-pager

よくある誤解：「タイマーがアクティブになっているので、ownCloudのcronは正常に動作している。」 タイマーがアクティブになっているということは、スケジューラが起動待ちの状態にあることを示すだけで、サービスが正常に呼び出される必要があります。

対処方法： PHPエラー、アクセス拒否メッセージ、ファイルの欠落、データベースエラー、またはゼロ以外の終了ステータスを探します。タイマーを繰り返し再起動するのではなく、最初に発生した具体的なエラーを修正してください。

ステップ8：オンデマンドで1回実行してownCloudを検証する

最終テストのために15分待つ必要はありません。

sudo systemctl start owncloud-cron.service
sudo systemctl status owncloud-cron.service
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ status

ワンショット実行が成功した後、systemctl statusサービスを非アクティブとして報告しつつ、同時にも表示することができますstatus=0/SUCCESS。重要な結果は、コマンドが正常に完了したということです。

手順：手動サービステストが成功した後、少なくとも1回のスケジュールされたタイマーの起動を待ち、手動操作なしで新しいジャーナルエントリが表示されることを確認します。

それでも実行できない場合は、レイヤーごとにトラブルシューティングを行ってください。

cron.phpと古いガイドに関する注意点

以前のownCloudの手順では、多くの場合、cron.php直接呼び出しが行われていました。現在のownCloudのドキュメントでは、 を推奨しておりocc system:cron、ownCloudのリリースノートでは、以前の直接cron.php呼び出し方式からの移行について説明しています。ownCloud Serverのリリースノートを参照してください。

対処法:古い crontab または systemd ユニットを引き継いで実行している場合はcron.php、それを保持する前に、インストールされている ownCloud リリースのドキュメントと比較してください。

最終確認チェックリスト

• ownCloudはCronによるバックグラウンドジョブ用に構成されています。
• occ system:cron意図したウェブサーバーアカウントでは、正確なコマンドが正常に実行されます。
• owncloud-cron.timer有効になっていますactive (waiting)。
• systemctl list-timers十分な時間が経過すると、次のアクティベーションと前のアクティベーションの両方が表示されます。
• journalctl -u owncloud-cron.serviceスケジュールされた実行が正常に完了したことを示します。
• この設定では、公式のownCloud Dockerイメージや他のスケジューラによって既に提供されているcronを重複して使用することはありません。

これらのチェックがすべて合格すれば、「タイマーが存在する」というだけでなく、systemdがジョブをスケジュールし、適切なアカウントでownCloudを起動し、実際のバックグラウンドジョブランナーを正常に完了させたことが確認されたことになります。