設定テストとreload
設定ミスは、打った瞬間には分からない
これまで何度も nginx -t を打ってきました。ここで、あれが何を守っているのかをはっきりさせます。
nginx は起動するときに設定を読みます。書き間違えたまま systemctl restart を打つと、いったん止まったあと、読み込みに失敗して立ち上がれません。つまりサイトが落ちます。しかも落ちたことに気づくのは、たいてい訪問者からの連絡です。
止まる前に気づくための道具が -t です。
nginx -t
# nginx: configuration file /etc/nginx/nginx.conf test is successful動いているサービスには一切触れず、設定が読めるかどうかだけを確かめます。
わざと壊すと、どこを直せばいいか分かる
設定の書き間違いで最も多いのは、行末のセミコロンの付け忘れです。試しに1つ外してみると、-t はこう答えます。
nginx: [emerg] directive "root" is not terminated by ";" in /etc/nginx/sites-available/mysite.conf:4
nginx: configuration file /etc/nginx/nginx.conf test failedファイル名と行番号まで出ています。エラーの文面を読まずに設定全体を眺め直す人が多いのですが、答えはたいていこの1行に書いてあります。まず読む、と決めてください。
最後の行が test is successful か test failed か。判定はここだけを見れば分かります。
reload は止めずに読み直させる
検査を通ったら反映します。ここで restart ではなく reload を使います。
systemctl reload nginx2章で見たとおり、restart は一度止めてから起動するので、その瞬間サイトが応答できません。reload は master プロセスを残したまま、新しい設定を読んだ worker を用意し、古い worker には処理中のリクエストを最後まで終わらせてから退場してもらいます。だから訪問者から見て途切れる時間が生まれません。
違いは Main PID を見れば分かります。
systemctl show -p MainPID --value nginx # 1234
systemctl reload nginx
systemctl show -p MainPID --value nginx # 1234 のまま2章の restart では番号が変わりました。ここでは変わりません。同じプロセスが設定だけを入れ替えた、ということです。
身につけるべき順番は3つ
設定を触るときの手順は、いつも同じです。書く、検査する、反映する。
vi /etc/nginx/sites-available/mysite.conf
nginx -t
systemctl reload nginx検査を飛ばして反映すると、reload そのものが失敗します。このとき nginx は古い設定のまま動き続けるので、サイトは落ちません。それでも「直したはずなのに変わらない」という混乱が起きます。順番を守るのが結局いちばん早い道です。
手を動かす
設定をわざと壊して -t に検知させ、その出力を記録します。そのあと直して検査を通し、reload で反映します。プロセスの番号が変わらないことも確かめます。