debug.log が 100MB を超えていた:内容の数え方と、記録を止めるまでの手順

セキュリティ対策
広告WordPress・PHP を学べる本

Amazonのアソシエイトとして、WordPress functions.phpは適格販売により収入を得ています。

wp-content の debug.log の大きさを見たら、100MB を超えていました。

外からは開けない設定になっていましたが、記録が止まらないまま、サーバーの容量を使い続けていました。

この記事では、debug.log の内容の見方と、記録を止めるまでの手順をまとめます。

debug.log ができる設定

wp-config.php に次の 3 行が入っていると、PHP のエラーや注意が wp-content/debug.log に書かれます。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

作っているときや、不具合を調べるときに設定して、そのままになっていることが多い設定です。

まず外から開けないかをチェックする

curl -s -o /dev/null -w '%{http_code}\n' https://(ドメイン)/wp-content/debug.log

200 が返ると、だれでも内容を読めます。内容には、サーバーの上のファイルの場所などが入っているので、すぐに止めます。

今回は 403 で、外からは開けない状態でした。

内容は種類ごとに数える

100MB を超えるファイルは、丸ごと開かずに、種類ごとの数を数えました。

grep -oE '^\[[^]]+\] PHP [A-Za-z ]+:' debug.log | sed -E 's/^\[[^]]+\] //' | sort | uniq -c | sort -rn
種類 意味 / 見るか
Fatal error 意味:処理が止まった見るか:必ず見る
Warning 意味:動いたが、おかしなところがある見るか:内容を見る
Notice・Deprecated 意味:今は動くが、書き方が古い・呼ぶ順番が早い など見るか:多いものだけ見る

今回の 2 つのサイトでは、ほとんどが Notice と Deprecated でした。

  • テーマが、翻訳を読み込むのが早すぎるという注意(13 万件)
  • PHP 8.2 で古くなった書き方(動的なプロパティ)の注意
  • WP-CLI を cron で動かしたときに出る、WP-CLI の中の注意

Fatal error は 2 件だけで、テーマを直している途中の数分に出たものでした。今のテーマには、その処理はありませんでした。

記録を止める

  1. debug.log を手元に取ってきて、圧縮してバックアップする(100MB が 1MB ほどになった)
  2. wp-config.php の WP_DEBUG_LOG を false にする(WP_DEBUG_DISPLAY は false のまま。画面にエラーを出さない)
  3. サーバーの debug.log を消す
  4. サイトが今までどおり表示されるかを確認する

不具合を調べるときは、そのときだけ WP_DEBUG_LOG を true に戻します。

まとめ

  • debug.log は、作っているときの設定のまま残っていると、ずっと大きくなり続ける
  • まず外から開けないかをチェックし、内容は種類ごとに数えて、Fatal error と Warning を先に見る
  • バックアップを取ってから、記録を止めてファイルを消す

SiteBeacon(サイトビーコン)

サイトが止まったら、すぐに気づける。

ホームページを 5 分ごとにチェックして、止まったとき・エラーが出たとき・SSL やドメインの期限が近いときに、メールでお知らせします。2 サイトまでは、ずっと無料で使えます。

SiteBeacon を見る サイトを直す相談をする

監視で気づいたあとの直す作業も、同じ担当がお受けします。