ログでサービスの状態を調べる
サービスが起動しない・応答しないときは、まずログを読むのが鉄則です。systemd 管理下のサービスは journalctl でログを横断的に確認でき、-u でサービスを絞り、-f で新着を追従します。Webサーバ固有のアクセス・エラーログは /var/log/nginx/ や /var/log/httpd/ にも出力されます。エラーメッセージをそのまま読むことが、原因切り分けの最短経路です。
サービスが起動しない、起動したのに応答しない。サーバ運用ではこうした事態が日常的に起こる。そのとき、設定を当てずっぽうに書き換える前に、必ずやるべきことがある。ログを読むことだ。
ログとは、システムやサービスが「いつ・何をしたか・何に失敗したか」を時系列で書き残した記録だ。多くの不具合は、起動に失敗したまさにその瞬間のログに、原因を示すエラーメッセージが残っている。
エラーメッセージをそのまま読むことが、遠回りに見えて実は原因切り分けの最短経路になる。
メッセージは英語のことが多く、いつも親切とは限らない。それでも根気よく読み込めば「どのファイルの何行目が悪い」「どのポートが既に使われている」といった具体的な手がかりが得られる。
🗃 散らばったログを一本化する journalctl
たくさんあるサービスのログは、どこを見れば追えるのか。RHEL/MiracleLinux系では、systemd 管理下のサービスのログは journald という仕組みに集約され、それを読み出すコマンドが journalctl だ。
引数なしの journalctl はシステム全体のログを時系列で表示するが、量が膨大なので、実務では対象を絞って使う。表示は less と同じ操作でページ送りでき、スペースで進み、/ で検索し、q で終了する。
特定のサービスのログだけを見るには -u オプションを使い、sudo journalctl -u nginx や sudo journalctl -u sshd のように指定する。これで、そのサービスが起動・停止・失敗した記録だけを追える。
ログには権限が要ることが多いため sudo を付ける。
さまざまなサービスのログが時刻順に1か所へまとまっているので、「Webサーバが落ちた前後に、ほかのサービスで何が起きていたか」を横断的に追える点も journalctl の強みだ。
サービスが起動に失敗したときは、まずこの journalctl -u サービス名 を開くのが基本動作になる。
🔧 調査を助けるオプションたち
journalctl にはトラブル調査を助けるオプションがそろっている。どれを知っておくと得をするか。
-f を付けると、新しく書き込まれるログをリアルタイムで追従表示する。たとえば別の端末でサービスを操作したり、ブラウザからアクセスしたりしながら、こちらで sudo journalctl -u httpd -f を回しておくと、その操作に対応するログが流れてくるのが見え、現象とログを結び付けられる。止めるときは Ctrl + c だ。
直近の出来事だけ見たいときは -n 50 で末尾50行に絞れ、--since "10 min ago" や --since today で時間帯を限定できる。
-e を付けると最新の行へ一気に移動し、-p err のように深刻度を指定すればエラー以上の重要なログだけを抜き出せる。
-b を付けると今回の起動以降のログだけに絞れるので、再起動してから調子が悪いというときに役立つ。
サービスが起動に失敗した直後なら、sudo journalctl -u nginx -n 50 で末尾だけ見れば、失敗の核心がたいてい見つかる。
なお journald のログは既定ではメモリ上に置かれ再起動で消える設定のこともあり、恒久的に残したい場合は /var/log/journal/ を用意して永続化する。
📄 journalctl だけでは足りない Webサーバ固有のログ
Webへのアクセスが届いているかどうかは、journalctl だけでは見えてこない。systemd のログとは別に、Webサーバはそれ自身のアクセスログとエラーログをファイルに出力しているからだ。
場所は決まっていて、nginx は /var/log/nginx/、Apache httpd は /var/log/httpd/ の下にある。
アクセスログ（access_log）には「いつ・どのIPから・どのページに・どんな応答コードで応えたか」が1行ずつ記録され、エラーログ（error_log）には設定の問題やファイルが見つからないといった異常が残る。
これらは普通のテキストファイルなので、tail -f /var/log/nginx/access.log のように tail で追えば、アクセスが届くたびに行が増えるのをリアルタイムで観察できる。
別端末でサイトにアクセスしながらこちらでログを眺めれば、「リクエストが届いているのか」「届いた上でエラーになっているのか」を切り分けられる。
🔎 どの語に目を留めるか
流れるログの中で何に目を留めればいいか。エラーが起きた時刻の前後と、error / failed / denied といった語を含む行に注目する。
たとえば Address already in use とあればポートの取り合い、Permission denied なら権限やSELinuxの問題、Syntax error on line ... なら設定ファイルの文法ミス、と当たりがつく。
RHEL系では、SELinux による拒否は /var/log/audit/audit.log に avc: denied として記録されるので、「設定は正しいはずなのに Forbidden になる」ときはこちらも見る価値がある。
1つのエラーを直しても直らないことがあるが、それは複数の原因が重なっている場合で、ログを手がかりに一つずつ潰していく。
⚠ つまずいたら、まずこれ
いちばんもったいない失敗は、ログを読まずに勘で設定を変え、かえって状態を悪くしてしまうことだ。
サービスが動かないときの実務の定番手順はこうだ。systemctl status サービス名 で Active: と直近のログ行を確認し、足りなければ journalctl -u サービス名 -n 50 で詳細を追い、Webサーバ固有の現象なら /var/log/nginx/ や /var/log/httpd/ のログも合わせて見る。
設定を変えながら原因を追うときは、片方の端末で journalctl -f を回しっぱなしにしておくと、変更の効果がその場で分かって調査が速く進む。
「困ったら、まずログ」を習慣にすることが、サーバ運用でいちばん効く基本動作になる。