はじめに
私はどうも細かいところで詰めが甘く、しくじることが多いのですが、今回もそんなことに気が付いたので、ここにメモしておきます。GCP x Bitnami x WordPress x LetsencryptでSSLの自動更新がかからない場合の対応です。
すべての設定が正しかったらcrondの再起動をしてみてください
技術Blogでは無いので、細かいことは書きませんが、crondで特定のスクリプトを実行するには、以下の条件が整っている必要があります。
- 実行対象スクリプトに実行権限を与えて、755にした
- crontabコマンドで設定ファイルを適切に編集した（実行タイミング、スクリプトのフルパスなどのことです）
簡単な話ですが、この二つがちゃんとできていると思っているにも関わらず、対象のスクリプトがうまく実行されない場合は、以下の確認をします。
- そもそも、スクリプト単体で実行可能かどうか。
これは、crondで定期処理を実行するよりも前に、まずは、そのコマンドがちゃんと実行可能なのかどうかを調べるという話です。そもそも、実行不可能なものをcrondから自動処理させてもそれは実行できるわけが無いので、まずは足元を固めます。 - crondは設定に従って、スクリプトを実行しに行っているか
特に、エラー出力を/dev/nullなどに吐き出して、エラーログを確認できないときなどは、処理がどこでエラーしているのか分からないので、まずは正しくcrondから呼び出されていることを、crondのログから確認します。
crondの実行ログがどこに書かれるのかは、ディストリビューションによっても違うのかもしれませんが、私の環境では/var/log/syslog当たりでした。crondが処理をする予定時刻のちょっと後ぐらいにログを確認して、処理された形跡があれば、crondは定義に従って、処理を実行したことが分かります。
このタイミングで、スクリプトがcrondから実行されていないことが判明したら、crondの再起動をしてみると状況が改善するかもしれません。crondの再起動はいろいろな方法があるとは思いますが、私は古い人間なので、init.dからrestartします。
$ /etc/init.d/crond restart
ですね。
私のケースでは、これでスクリプトが実行されない問題は解消しました。 - crondが実行したスクリプトは自分が意図したものか
このログには、ユーザーが指定したスクリプトなどのパスが書いてあるので、そのパスが本当に正しいのかを確認することは、エラーの切り分けに十分に役に立つと思います。
私は、このログを見ることで、スクリプトへのパスが間違っていることに気が付き、修正し、正しく処理が進むようにできました。
まとめ
- Bitnamiのフォーラムを見ると、この問題で悩んでいる人がかなりいるようなので、私のケースの解決策を提示しておきました
- サーバーの動きは、慣れていない人には分からないのかもしれませんが、プリミティブなところから、順を追って考えていくと必ず答えにたどり着けると思うので、同じく悩みを抱えている方も頑張ってください。