systemd で Nextcloud の Cron ジョブが自動的に実行されない問題を修正する

Systemd を使用して Nextcloud のバックグラウンド ジョブを自動的に実行するには、Web サーバー ユーザーとして実行されるワンショット サービスを設定しcron.php、そのサービスを 5 分ごとに起動するタイマーを有効にします。重要なチェック事項は、タイマーが有効になっていて、次の実行時刻が設定されていること、サービスが正しい Nextcloud および PHP パスを指していること、そしてサービス ジャーナルに正常に終了したことが記録されていることです。ワンショット サービスでは、実行間隔中に「非アクティブ (停止)」と表示される場合がありますが、これはサービス終了後は正常な状態です。

この設定は、ホスト上に Nextcloud ファイルが配置された、systemd を使用した Ubuntu への一般的な Nextcloud インストール用です。Nextcloud が Docker、Snap、または Nextcloud All-in-One などのアプライアンス内で実行される場合は、ホストユニットをコンテナ専用パスに指定するのではなく、そのディストリビューションのドキュメントに記載されているスケジューラ方式を使用してください。以下の例では と を使用しています/var/www/nextcloudがwww-data、実際のインストールパスと HTTP ユーザーに置き換えてください。

タイマーが達成すべきこと

Nextcloudは、cron.phpメンテナンスやアプリタスクなどのバックグラウンド処理をキューに入れて実行します。systemdタイマーはタイマーの時刻であり、サービスはタイマーが経過したときに実行されるコマンドです。どちらも必要です。タイマーを有効にせずにファイルを作成するとスケジュールが無効になり、PHPやNextcloudのパスが間違っているタイマーを有効にすると、実行が繰り返し失敗する可能性があります。

Nextcloudは、本番環境のバックグラウンドジョブにはシステムcronの使用を推奨しています。最新の管理マニュアルでは、代替手段としてsystemdタイマーについても記載されています。この例のスケジュールは、起動から5分後に開始し、各サービスの起動から5分後に再度実行されるように設定されています。これにより、ユーザーがWebインターフェースにアクセスする必要がなくなります。

1. インストールパス、ユーザー、およびPHP CLIを確認します。

ユニットを編集する前に、実際の Nextcloud ディレクトリを見つけて、Web サーバーのインストールで想定されている PHP コマンドを確認してください。一般的な Ubuntu アーカイブのインストールでは、パスは/var/www/nextcloud、Web ユーザーはwww-data、PHP CLI は です/usr/bin/php。推測するのではなく、確認してください。

ls -l /var/www/nextcloud/cron.php
command -v php
php -v

Nextcloud ディレクトリが別の場所にある場合は、以下の両方のユニットコマンドでそのディレクトリに置き換えてください。Web サーバーが別の PHP バージョンを使用している場合は、そのバージョンの CLI 実行可能ファイルを と で使用してくださいExecStart。systemdExecConditionサービスは対話型シェルの PATH や環境を継承しないため、明示的なパスの方が信頼性が高くなります。

systemdが使用するのと同じユーザーでステータスチェックをテストしてください。

sudo -u www-data /usr/bin/php -f /var/www/nextcloud/occ status -e

Nextcloudのoccコマンドは、正しいファイル所有権とアクセス権限を維持するために、HTTPユーザーとして実行する必要があります。このテストでPHPエラー、メンテナンスモード、またはファイルの欠落が報告された場合は、まずそれらを修正してください。タイマーはNextcloudコマンドの失敗を補償することはできません。

2. ワンショットサービスを作成する

作成する/etc/systemd/system/nextcloudcron.service：

sudo nano /etc/systemd/system/nextcloudcron.service

インストール環境が異なる場合は、パスとユーザーを調整して、このユニットを入力してください。

[Unit]
Description=Nextcloud cron.php job

[Service]
User=www-data
ExecCondition=/usr/bin/php -f /var/www/nextcloud/occ status -e
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php
KillMode=process

ExecConditionバックグラウンド ジョブを開始する前に、Nextcloud が正常に動作しているかどうかを確認します。条件を満たさない場合、systemd は実行をスキップします。理由を確認するには、ジャーナルを調べてください。KillMode=processバックグラウンド ジョブによって起動された外部プログラムが、メインの cron プロセスが終了した後も継続できるようにします。現在の Nextcloud の例では、このサービス ファイルにセクションは必要ありません[Install]。

を使用するの/usr/bin/phpは、それがサーバー上で正しいCLIインタープリタである場合に限ります。たとえば、カスタムPHPリポジトリでは、バージョン管理されたバイナリがインストールされる場合があります。Nextcloudが必要とするPHPバージョン、およびそのWebサーバー構成で使用されているPHPバージョンと同じ互換性のあるバージョンを使用してください。

3. タイマーを作成する

作成する/etc/systemd/system/nextcloudcron.timer：

sudo nano /etc/systemd/system/nextcloudcron.timer

追加：

[Unit]
Description=Run Nextcloud cron.php every 5 minutes

[Timer]
OnBootSec=5 min
OnUnitActiveSec=5 min
Unit=nextcloudcron.service

[Install]
WantedBy=timers.target

OnBootSec起動時にsystemdが起動してから5分後に最初の実行をスケジュールします。OnUnitActiveSecまた、サービスが最後にアクティブ化されてから5分後にも再度実行をスケジュールします。タイマーはサービスとは異なります。.timerスケジュールを自動的に実行するには、ユニットを有効にして起動してください。

4. systemdをリロードしてタイマーを有効にする

systemdに新しいユニットファイルを読み込ませ、タイマーを有効にして起動させるコマンドを1つ実行します。

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

タイマーを確認してください：

systemctl status nextcloudcron.timer
systemctl list-timers --all | grep nextcloudcron

タイマーはロードされてアクティブになっている必要があり、list-timersNEXT の下に将来の時刻が表示されている必要があります。無効になっている場合、ロードされていない場合、または次のアクティブ化がない場合は、ファイル名が で終わっていること.timer、[Install]セクションに が含まれていることWantedBy=timers.target、およびdaemon-reloadファイルを保存した後に を実行したことを確認してください。

5. 1つのテストを実行し、その結果を確認する。

次のタイマーティックを待たずに、サービスを一度起動することができます。

sudo systemctl start nextcloudcron.service
sudo systemctl status nextcloudcron.service
sudo journalctl -u nextcloudcron.service -n 50 --no-pager

サービスの実行結果と、PHPまたはNextcloudのエラーを確認してください。コマンドが完了すると、ワンショットタスクであるため、元の状態nextcloudcron.serviceに戻る場合がありますinactive (dead)。ただし、それだけで失敗したとは限りません。タイマーはアクティブなままで、次の実行がスケジュールされます。ジャーナルには、前回の実行が正常に終了したかどうかが表示されます。

Nextcloud管理画面で、バックグラウンドジョブのステータス画面を開き、タイマーが作動した後に最終ジョブ実行時刻が進むことを確認してください。Nextcloudが最近のバックグラウンドアクティビティを検出すると、概要警告が消えるはずです。タイマーを有効にしてから、スケジュールが実行されなかったと判断する前に、少なくとも1回の間隔を置いてください。

一般的な故障パターンを診断する

詳細については、最近のサービスログとNextcloudログファイルを確認してください。

sudo journalctl -u nextcloudcron.service --since "30 minutes ago" --no-pager
sudo -u www-data /usr/bin/php -f /var/www/nextcloud/occ background-job:list

ジョブリストには登録された作業が表示されますが、それだけではタイマーが実行されていることの証明にはなりません。タイマーの最終起動時刻と次回起動時刻、サービスジャーナル、およびNextcloudの最終実行インジケーターを併用してください。

別のスケジューラを使用するタイミング

systemd タイマーは、サーバーが systemd で動作していて、ローカルでサービス管理されたスケジュールが必要な場合にうまく機能します。標準の cron デーモンを既に運用していて、その crontab を確認できる場合は、同じものを呼び出すシステム cron エントリcron.phpもwww-dataサポートされています。同じ Nextcloud インスタンスに対して両方の方法をスケジュールしないでください。呼び出しが重複すると、リソースが浪費され、トラブルシューティングが複雑になる可能性があります。

AJAX スケジューリングは Nextcloud にアクセスするユーザーに依存するため、負荷の高いサーバーやマルチユーザーサーバーでは信頼性が低くなります。Webcron はcron.phpHTTP 経由で呼び出しを行うため、システムアクセスが利用できない非常に小規模なインスタンスには適している可能性がありますが、Nextcloud では Web 実行によって呼び出しごとに実行できる処理量が制限されることに注意してください。Nextcloud がコンテナ化されている場合、またはアプライアンスによって管理されている場合は、サポートされているスケジューラまたはコンテナ構成を使用してください。/var/www/nextcloudホストにそのパスが存在しない場合、ホストサービスでは動作しません。

正常な設定では、タイマーが有効になっており、次回実行時刻が定期的に設定され、サービスがPHPエラーなしで完了し、Nextcloudの最終実行時刻が進んでいます。これら3つの条件がすべて満たされているにもかかわらず、特定のアプリタスクが遅延しているように見える場合は、そのジョブが独自のスケジュール、メンテナンスウィンドウ、またはキュー条件を待っている間にスケジューラが動作している可能性があります。タイマー間隔を変更する前に、そのジョブを個別に診断してください。

公式資料

• Nextcloud 35 管理マニュアル：バックグラウンドジョブとsystemdタイマー
• Nextcloud 管理マニュアル：occ コマンドの使用方法
• Nextcloud 35 管理マニュアル：バックグラウンドジョブコマンド
• Ubuntu 24.04 systemd.timer マニュアル