journalctlでログを読む

起動に失敗したとき、答えはログにある

systemctl status が failed と言っても、なぜ失敗したかまでは数行しか教えてくれません。理由が書いてあるのはログのほうです。systemd が管理しているサービスのログは、journalctl でまとめて読めます。

-u は unit の指定で、そのサービスに関する行だけを取り出します。付けずに打つと、システム全体のログが出てきて目的の行を見失います。まず -u から、と覚えてください。

出力を扱いやすくする3つの指定

そのままではページャに入って対話操作になり、量も膨大です。実用では次の3つをよく足します。

-n 20 は末尾20行だけ。障害を調べるときに見たいのは、たいてい直近の出来事です。--no-pager はページャを使わず、そのまま流す指定です。スクリプトの中やファイルへの保存では必須になります。

時間で絞る書き方もあります。

「いつから壊れているか」が分かっているときは、こちらのほうが早く目的に届きます。

深刻さで絞る

ログには深刻さの段階が付いています。エラー以上だけを見たいときは -p で指定します。

正常な起動の記録は流れず、問題のある行だけが残ります。行数が多くて読む気が失せるときの最初の一手です。

流れ続けるログを見る

-f を付けると、新しい行が出るたびに追加で表示されます。

この状態では入力が戻ってきません。別の端末からリクエストを送り、ログがどう出るかを同時に見る、という使い方をします。止めるときは Ctrl と c を同時に押します。

このサンドボックスでの注意

学習用の環境では、ログはメモリ上に保持されています。ディスクに残す設定にしていないため、本当の意味での再起動をまたぐと消えます。実際のサーバーでは /var/log/journal を作ると永続化され、過去の障害まで遡れます。この違いは覚えておいてください。

手を動かす

nginx を再起動してログを新しく作り、直近の記録をファイルに残します。エラーだけを抜き出す指定も試します。