WordPress wp-cron.php を止める

　wp-cron.php は、
時間と連動した処理で起動されるスクリプトで、
・記事の予約投稿
・メール投稿
・XML-Sitemap
などで使用される。

wp-cron.php は、Dos攻撃などの不正アクセスに利用されることがあり、アクセス制限を掛ける方が良い。

問題は、
アクセスが発生する度に起動されるので、アクセス数が増えると、サーバへの負荷が掛かってしまう。

例えば、ユーザーがサイトにアクセスすると wp-config.php が起動され、予約投稿の記事が無いかを確認する。毎回これが行われるので、アクセス数が多いサイトだと、サイトのパフォーマンスにも大きく影響する。

→　wp-config.php 自体を無効にすることが推奨されている。

nginxのアクセスログから「wp-cron.php」を抜き出した例。

# nginxのアクセスログを出力
access_log  /var/log/nginx/access.log;

/** wp-cronを止める */			
define('DISABLE_WP_CRON', 'true');

「wp-config.php」への追記例。

sudo crontab -e

35 * * * * curl https://arakan60.site/wp-cron.php > /dev/null 2>&1

nginxのアクセスログを見ると、「wp-cron.php」が1時間毎に実行されるようになった。

　HTTP / HTTPS経由での実行は、望ましくありません。

Webサーバー経由でアクセスすると、その分サーバーにオーバーヘッドが生じます。Webサーバーは、通信時に全体のコンテンツの長さを計算してレスポンスヘッダーに記載したり、圧縮処理を実行したり、名前解決などでネットワークを経由したり、キャッシュサーバーを利用している場合はトラフィック自体がネットワーク上を流れてしまったりするなど、様々な点でコマンドでの実行と比べ動作が遅くなる可能性を孕んでいます。また、Webサーバーが起動していないと動作せず、エラーを吐きます。

なお、この方法の場合は処理自体がWebサーバーを経由する（WebサーバーのユーザーがPHPファイルを読み込む）ため、rootユーザーで実行しても大丈夫です。

#!/bin/sh


# wp-config.php の実行
/usr/bin/php -q /home/yaopi/www/wordpress/wp-cron.php >/dev/null 2>&1
#

sudo crontab -e

# wp-config.php の実行
35 * * * * /etc/cron.hourly/wp-cron.sh

php のパスを確認した例。

　PHP コマンドラインオプション  【-q】
"-q"オプションを付けることで、HTTPヘッダを自動出力させないようにする。

　/dev/null（nullデバイスとも呼ばれる）とは
　UNIXやUnix系オペレーティングシステム (OS) におけるスペシャルファイルの1つで、そこに書き込まれたデータを全て捨て（writeシステムコールは成功する）、読み出してもどんなプロセスに対してもデータを返さない（EOFを返す）。
　/dev/null は通常、プロセスの不要な出力ストリームを捨てるのに使う。

　>/dev/null 2>&1

①標準出力
標準出力だけを出す場合
/path/script.sh 1> /path/exec.log

②エラー出力
エラー出力だけ出す場合
/path/script.sh 2> /path/error.log

③標準出力とエラー出力その1
両出力を一つのファイルに出す場合
/path/script.sh > /path/both.log 2>&1

④標準出力とエラー出力その2
それぞれの出力を別々のファイルに出す場合
/path/script.sh 1> /path/exec.log 2> /path/error.log

➡️ シェルスクリプト。

#!/bin/sh

# 実行した日時をログに書き込む
echo "[$(date)] ===== wp-cron.php 実行開始 =====" >> /var/log/wp-cron.log

# WordPressを実行（エラー出力があればそれもログに流す）
/usr/bin/php -q /home/yaopi/www/wordpress/wp-cron.php >> /var/log/wp-cron.log 2>&1

# 結果コードをログに書き込む
echo "結果コード: $?" >> /var/log/wp-cron.log
echo "-------------------------------------" >> /var/log/wp-cron.log


➡️ ログファイルを作成し、権限を与える。
sudo touch /var/log/wp-cron.log
sudo chmod 666 /var/log/wp-cron.log

➡️ 手動で実行してみる。
sudo /etc/cron.hourly/wp-cron.sh

➡️ ログを確認する。
cat /var/log/wp-cron.log

php のパスと、WEBサーバーの実行ユーザーを確認した例。

35 * * * * ユーザー /etc/cron.hourly/wp-cron.sh

エラーメッセージ。
(CRON) error (grandchild #4525 failed with exit status 127)

crontab への登録結果。

シェルスクリプトの内容。

「ユーザー指定」をして登録すると、エラーが出なくなる。

「ユーザー指定」をしたcronの設定は「/var/spool/cron/crontabs/[ユーザ名]」で保存されている。

crontabコマンドの使い方。

cron のログ行がコメントアウトされているので、 # を消す。

全て表示する様に、足して15にする：EXTRA_OPTS='-L 15'。

cron のログファイルの内容。

「chkconfig」で、自動起動するサービスを確認してみる。

「rsyslog」の自動起動設定と確認事例。

「rsyslog」の自動起動設定を行うと、【reboot】後も cron のログが書かれるようになった。

　「rsyslogd」
システムのログを記録するデーモン。「syslog」と呼ばれる。
syslogdの代わりに「rsyslogd」が動いている。