サーバーが起動に失敗した場合、その回のジャーナルログは再起動後もあとから参照できます。systemdのジャーナルには複数回分の起動記録が保持されており、いつ・どのサービスが・どのようなエラーを出して処理が止まったかを後から確認することが可能です。この記事では、失敗した起動の回を特定し、ログを取り出してエラーに絞り込むまでの手順を順に説明します。
ジャーナルに過去の起動記録が残っているか確かめる
最初に、過去の起動記録が参照できる状態かを確認します。次のコマンドで、保存されている起動回の一覧を表示できます。
journalctl --list-boots
現在の起動(インデックス 0)しか表示されない場合、ジャーナルの永続化が有効になっていない可能性があります(設定は /etc/systemd/journald.conf の Storage= 行で確認できます)。複数行が表示されれば、過去の起動記録を参照できます。
起動一覧から失敗した回を見つける
一覧の各行には、左からインデックス番号・ブートID・最初のエントリの日時・最後のエントリの日時が並んでいます。インデックスは 0 が現在の起動、-1 が一つ前、-2 が二つ前を指します。
次は想定例です。
-3 a1b2c3d4... Sun 2026-10-18 22:14:08 JST—Mon 2026-10-19 00:30:44 JST
-2 e5f6a7b8... Mon 2026-10-19 02:10:05 JST—Mon 2026-10-19 02:10:41 JST
-1 c9d0e1f2... Mon 2026-10-19 09:31:22 JST—Mon 2026-10-19 09:32:03 JST
0 d3e4f5a6... Mon 2026-10-19 12:05:44 JST—Mon 2026-10-19 15:18:30 JST
この想定例では、-2 と -1 の最初と最後のエントリの時刻差がそれぞれ約36秒・約41秒です。正常に稼働した -3(約2時間16分)や現在の起動 0(約3時間13分)と比べると極端に短く、この2回が起動途中で停止した可能性を示しています。このように最初と最後の時刻差が短い回が、失敗した起動の候補になります。複数回連続して短時間の起動が並んでいる場合は、繰り返し再起動を試みた痕跡とも読めます。
失敗した回のログを取り出す
確認したいインデックス番号を指定してログを表示します。直前の起動を参照する場合は次のとおりです。
journalctl -b -1
さらに前の起動を確認するときは番号を変えます。
journalctl -b -2
その後の再起動でインデックスがずれている場合や、番号ではなく記録を確実に特定したい場合は、--list-boots の出力にあるブートIDで直接指定できます。
journalctl -b e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
出力はページャーで表示されます。起動シーケンスのどこで止まったかを調べるには、末尾から逆順にさかのぼるとログが途切れる直前のメッセージに効率よくたどり着けます。
エラーや警告に絞って手がかりを探す
その回の全ログを通読するよりも、まずエラー以上のメッセージだけに絞ると手がかりを見つけやすくなります。
journalctl -b -1 -p err
エラーの件数が少なく、警告レベルも合わせて確認したい場合は warning を指定します。レベルを1つだけ指定すると、そのレベル以上(warning・err・crit・alert・emerg)がまとめて表示されます。
journalctl -b -1 -p warning
絞り込んだ出力を読む際は、タイムスタンプに注目しながら前後のメッセージと照らし合わせます。エラーが出た時刻の直前に記録されているメッセージを確認すると、カーネルの初期化・ファイルシステムのマウント・各サービスの起動のどの段階で処理が止まったかの見当をつけやすくなります。
特定のサービスのログだけ取り出す
エラーメッセージからサービス名に見当がついたら、そのユニットを指定して絞り込むと関連するメッセージだけを参照できます。
journalctl -b -1 -u ユニット名.service
失敗したユニット名はエラーメッセージ中に含まれていることが多いため、前の手順で絞り込んだ出力を起点にするのが実際的な進め方です。なお systemctl list-units --state=failed は現在の起動セッションの状態を返すコマンドのため、過去の起動回の失敗したユニットは表示されません。
よくあるつまずきと確認ポイント
前の回を指定しても記録が見つからない
ジャーナルが揮発性領域(/run/log/journal/)にのみ書かれている設定では、再起動後にその回の記録が消えます。既定の Storage=auto のまま /var/log/journal/ ディレクトリが存在しない環境ではこの状態になっています。dmesg が表示するのは現在動いているカーネルのリングバッファなので、前の回の記録は含まれません。ログが残っていない場合は、ハードウェアのBMC・UEFIのイベントログ、シリアルコンソールの記録が調査の起点になります。
指定した番号やブートIDの回が見つからない
指定したインデックスまたはブートIDが現在のジャーナルに存在しない場合は、記録が見つからない旨のメッセージが出ます。journalctl --list-boots で表示される範囲に収まっているか確認してください。-1 や -2 のような負の番号は最新の回から数えるため、その後に再起動すると同じ回の番号が1つずつずれます。
失敗した起動がリストにまったく表示されない
カーネルパニックや突然の電源断のように、ジャーナルへの書き込みが完了しないまま停止した場合、その回の記録が残らないことがあります。一覧には起動の痕跡がまったく現れないため、ジャーナル以外の手段での調査が必要になります。
「コマンドは打てる。次は”現場で通用する型”を最短で身につけたい」——そんなあなたへ。
ネットの断片的なTipsをコピペするだけでは、体系的な運用スキルはなかなか積み上がりません。リナックスマスター.JPの無料メルマガ「リナマガ」では、現場で実際に使うLinuxサーバー運用の考え方を、順を追って実務目線でお届けしています。いま登録された方には、安全なサーバー構築の「型」をまとめた『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼント中です。
>> 図解60P『Linux入門マニュアル』を無料で受け取る
(メルマガ登録は10秒・いつでも解除OK)
※ 「独学の時間がもったいない」「プロから現場の技術を最短で学びたい」という本気の方には、2日で実務レベルが身につく初心者向けハンズオンセミナーもご用意しています。
