Cron ジョブの設定と管理

A cron job runs a command on a schedule, in the background, whether or not anyone is visiting your site. This guide covers adding one in KPanel, writing the schedule and the command correctly for…

cronジョブはコマンドをスケジュールに従い、バックグラウンドで実行します。サイトにアクセスがあるかどうかに関係なく動作します。このガイドでは、KPanelでの追加方法、このプラットフォーム用のスケジュール・コマンドの正しい書き方、WordPressの信頼性の低い組み込みスケジューラの置き換え、およびジョブが期待通りに動作しない場合の出力の確認方法について説明します。

KPanelでのCronの位置

Cronはサイトに属しているため、メインメニューではなくサイトからアクセスします。

KPanelにサインインし、左サイドバーのWebsitesをクリックします。
対象のサイトをクリックします。
サイト自身のメニューでAdvancedを開き、その後Cronを開きます。

直接アクセスできるアドレスは/websites/<site-id>/cronです。既存のジョブテーブルが表示されるか、サイトにジョブがない場合は空の状態が表示されます。

KPanelのサイトのCronジョブ

ジョブの追加

右上のAdd Cron Jobをクリックします。フォームには3つのフィールドがあります。

Schedule

6つのプリセットボタンで式を入力できます。

ボタン	式
Every minute	`* * * * *`
Every 5 min	`/5 * * *`
Every hour	`0 * * * *`
Daily 2AM	`0 2 * * *`
Weekly Sunday	`0 2 * * 0`
Monthly 1st	`0 2 1 * *`

またはCron expressionに独自のスケジュールを入力します。5つのフィールドの順序は、分、時間、月の日、月、週の日です。

minute  hour  day-of-month  month  day-of-week

0 3 * * *は毎日午前3:00に実行されます。
*/15 * * * *は15分ごとに実行されます。
0 9 * * 1は毎週月曜日の午前9:00に実行されます。
30 1 1 * *は毎月1日の午前1:30に実行されます。
0 */6 * * *は6時間ごと、ちょうどの時刻に実行されます。

Label

後で認識するための名前。例えばWordPress cronやNightly stock syncなど。ジョブテーブルに表示されるので、わかりやすいものにしてください。job 3では午前2時の役に立ちません。

Command

実行するシェルコマンド。Saveをクリックしてジョブを作成します。

完全パスを使用してください。Cronは最小限の環境で実行され、シェルプロファイルが読み込まれないため、SSH経由でログインしているときに機能するphpまたはディレクトリは、ここでは失敗します。毎回、完全なパスを記述してください。

コマンドの記述

ジョブはサイトの独自のシステムユーザーとして実行されるため、ホームディレクトリが適切なアンカーになり、~は正しく解決されます。サイトのファイルは次の場所にあります。

~/htdocs/yourdomain.co.nz

サイトのFilesタブ、その後SFTPタブで正確なパスを確認できます。Site filesの下に記載されています。

典型的なコマンド：

cd ~/htdocs/yourdomain.co.nz && /usr/bin/wp cron event run --due-now

cd ~/htdocs/yourdomain.co.nz && /usr/bin/php bin/send-queued-emails.php

/usr/bin/curl -fsS https://yourdomain.co.nz/api/nightly-report

スケジュール前にコマンドをテストしてください。それがwpコマンドの場合は、サイトのWordPress、その後Consoleセクションに貼り付けるか、SSH経由で実行します。最初から機能しないジョブは、午前3時のログファイルでより見つけやすくなります。

WordPressの組み込みスケジューラの置き換え

WordPressは独自の疑似スケジューラWP-Cronで提供されており、ページが読み込まれたときのみ実行されます。アクセスが少ないサイトでは、スケジュール投稿の公開が遅れ、メールがキューに溜まります。アクセスが多いサイトでは、すべての訪問者がスケジュール確認のコストを負担します。

本物のcronジョブで解決します。KPanelは全体の交換を行います。

サイトを開き、WordPressタブを開きます。
WP-Cronセクションを開きます。
Enable system cronをクリックします。

これにより、5分ごとにWP-Cronを実行するスケジュールが追加され、DISABLE_WP_CRONが設定されるため、ページロードがトリガーされなくなります。同じ画面のRemove system cronで両方をキャンセルします。

手動で行う場合は、2つのステップです。

訪問者がトリガーするバージョンを無効にします。 Files、その後File Managerを使用して、/* That's all, stop editing! */行の上のwp-config.phpに以下を追加します。

define( 'DISABLE_WP_CRON', true );

本物のジョブを追加します。 Advanced、その後Cronで：

Schedule: */5 * * * *
Label: WordPress cron
Command: cd ~/htdocs/yourdomain.co.nz && /usr/bin/wp cron event run --due-now

DISABLE_WP_CRONの半分をスキップしないでください。両方が実行されている場合、スケジュール済みの各タスクは2回実行される可能性があります。重複するメール、重複する注文処理、サブスクリプションプラグインでの重複請求です。WP-Cronセクションのワンクリックアクションを使用すれば、これはできません。

WooCommerceとバックグラウンドキュー

WooCommerceは注文ステータスの変更、サブスクリプション更新、メール、在庫更新のためにバックグラウンドキューを使用します。WP-Cronに依存しているため、アクセスが少ないストアではまさにこのワークロードが影響を受けます。

本物のスケジュールが設定されたら、キューは5分ごとに処理されます。wp-adminのWooCommerce、その後Status、その後Scheduled Actionsで確認できます。

高容量ストアは*/2 * * * *に移行できます。それより低くすることはほぼ役に立ちません。プロセスを開始するのに時間を費やすより、作業をする方が重要です。Setting Up WooCommerceを参照してください。

既存のジョブの管理

ジョブテーブルにはLabel、Schedule、Command、Last run、Statusが表示され、各行に2つのアクションがあります。

Disableはジョブを一時停止するだけで、削除はしません。復活させるにはEnableに変わります。ジョブが問題を引き起こしているかどうかをテストする場合に使用します。
Deleteは完全に削除します。確認を求められ、スケジュール実行は直ちに停止します。

cronジョブの削除は取り消せません。スケジュールはサーバーから直ちに削除されます。一時的に停止しようとしている場合は、Disableを使用してください。

出力の検索

Kapsuleが作成するすべてのジョブは、出力がキャプチャされます。標準出力とエラーはサイトユーザーのホームディレクトリ内のcron-logsディレクトリ内のログファイルに追加されます。ジョブごとに1つのファイルがあります。

このログはほぼすべての「ジョブは実行されたか？」という質問に答えてくれます。コマンドが出力した内容とそれが発生させたエラーが記録されているからです。

これを読むには、SSHで接続して~/cron-logs/を確認します。SSHは鍵認証を使用するため、最初にサイトのFilesから公開鍵を追加します。その後SSH Keysタブを確認してください。Adding SSH Keysを参照してください。

ファイルマネージャーおよびSFTPアカウントはサイトディレクトリ~/htdocs/yourdomain.co.nzに限定されており、cron-logsはその1つ上に位置しています。これは意図的です。SFTPアクセス権を持つ請負業者をWebサイト以外のすべてから除外しておくためです。ログにアクセスするにはネイティブSSHを使用するか、以下に示すように出力をサイトディレクトリにリダイレクトしてください。

ファイルマネージャーが開くことができるどこかに出力がある場合は、自分自身でリダイレクトしてください。

cd ~/htdocs/yourdomain.co.nz && /usr/bin/wp cron event run --due-now >> ~/htdocs/yourdomain.co.nz/wp-content/cron.log 2>&1

2>&1はエラーを通常の出力と同じファイルに送信します。これがない場合、エラーはどこにも行きません。

サイトディレクトリ内のものはすべて、Webで要求される可能性があります。リダイレクトされたログはサイトルートではなくwp-contentの下に配置し、推測されないような名前を付け、デバッグが完了したら削除してください。

ベストプラクティス

スケジュールを分散させてください。 6つのジョブがすべて0 2 * * *に設定されている場合、すべて一度に開始します。分散してください。0 2、10 2、20 2のように。
本当に必要でない限り、1分ごとを使用しないでください。 */5はWordPressやWooCommerceを含むほぼすべてに十分です。
ジョブを短く保ってください。 間隔より長くかかるジョブは次の実行と重なります。
ノイズのあるものは出力をリダイレクトしてください。 1つの騒々しいジョブがディスクを満杯にしないようにするために。
時々リストを確認してください。 削除したプラグインから残されたジョブは実行し続けます。

トラブルシューティング

ジョブが実行されないようです。 最初にパスを確認してください。ログファイルを開きます。次にステータスがActiveであり、Disabledではないことを確認します。その後、同じコマンドをSSH経由で実行して、何が表示されるかを確認します。

ログに「command not found」が表示される。 完全パスが不足しています。裸の名前ではなく/usr/bin/php、/usr/bin/wp、/usr/bin/curlを使用してください。

Permission denied。 ジョブはサイトのシステムユーザーとして実行されます。そのユーザーは、コマンドが接するすべてのものを所有するか、少なくともそれを読むことができる必要があります。Using the File Managerでアクセス権を確認します。

WordPressタスクはまだ遅く実行されます。 スワップの両方の半分が配置されていることを確認してください。スケジュールはAdvanced、その後Cronに存在し、DISABLE_WP_CRONが設定されています。WordPressタブのWP-Cronセクションに両方の現在の状態が表示されます。

ジョブが実行されているときにサイトが遅くなります。 より静かな時間帯に移動するか、作業をより小さなバッチに分割します。サイトレベルのリソース使用はPerformanceの下に表示されます。Improving Website Speedを参照してください。

プラグイン更新後、ジョブが動作しなくなりました。 コマンドパスが変更された可能性があります。ログを確認し、ジョブテーブルから古いジョブを削除して修正されたコマンドを追加してジョブを更新します。