ログでサービスの状態を調べる
サービスが起動しない・応答しないときは、まずログを読むのが鉄則です。systemd 管理下のサービスは journalctl でログを横断的に確認でき、-u でサービスを絞り、-f で新着を追従します。Webサーバ固有のアクセス・エラーログは /var/log/nginx/ や /var/log/httpd/ にも出力されます。エラーメッセージをそのまま読むことが、原因切り分けの最短経路です。
サービスが起動しない、起動したのに応答しない——サーバ運用ではこうした事態が日常的に起こります。そのとき、設定を当てずっぽうに書き換える前に必ずやるべきなのが、ログを読むことです。ログとは、システムやサービスが「いつ・何をしたか・何に失敗したか」を時系列で書き残した記録です。多くの不具合は、起動に失敗したまさにその瞬間のログに、原因を示すエラーメッセージが残っています。エラーメッセージをそのまま読むことが、遠回りに見えて実は原因切り分けの最短経路です。メッセージは英語のことが多く、いつも親切とは限りませんが、根気よく読み込めば「どのファイルの何行目が悪い」「どのポートが既に使われている」といった具体的な手がかりが得られます。
systemd のログを横断する 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/ を用意して永続化します。
Webサーバ固有のログ
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 を回しっぱなしにしておくと、変更の効果がその場で分かって調査が速く進みます。「困ったら、まずログ」を習慣にすることが、サーバ運用でいちばん効く基本動作です。