Skip to content
VDS · 監視とパフォーマンス

systemdログ：journalctlをわかりやすく解説

ログからサービスの障害原因を特定する方法、時間やレベルで必要な情報を絞り込む方法、ログがディスクを圧迫しないようにする方法を説明します。

更新日 2026年8月23日

システム上で起きるほぼすべての出来事は、最終的に systemd ジャーナルに記録されます。サービスが起動しない、マシンが勝手に再起動した、サイトが 502 を返す――答えはたいていすでに記録されています。あとは、その尋ね方を知るだけです。

これだけで十分な 5 つのコマンド

journalctl -u nginx -n 50 --no-pager      # last 50 lines of one service
journalctl -u nginx -f                    # follow in real time
journalctl -p err -b                      # only errors since boot
journalctl --since "10 min ago"           # everything for the last ten minutes
journalctl -b -1 -e                       # previous boot log, end of file

最後のものは、突然の再起動の後に特に役立ちます。-b -1 は前回のセッションを開き、その末尾でカーネルパニックだったのか、OOM killer が動いたのか、それとも正常なシャットダウンだったのかを確認できます。

-p のレベルは emerg、alert、crit、err、warning、notice、info、debug です。指定したレベルには、それより重要なものすべてが含まれます。

起動に失敗したサービスの診断

systemctl status myapp
journalctl -u myapp --since today -p warning

systemctl status は終了コードと最後の数行を表示し、journalctl は全体像を表示します。確認すべき点は次のとおりです。

  • Main process exited, code=exited, status=1 — アプリケーションが自力でエラー終了した。原因はその 1 行上にあります。
  • Failed to start ... Permission denied — ファイルやディレクトリの権限、または 1024 番未満のポートが原因です。
  • カーネルからの Killed process ... (java) total-vm... — OOM killer が作動しました。メモリ不足をお読みください。
  • Start request repeated too quickly — サービスがクラッシュループに陥り、systemd が起動を停止しました。原因を修正して systemctl reset-failed myapp を実行してください。

システム上で壊れているものすべての一覧は systemctl --failed です。

時間を節約するフィルター

journalctl --since "2026-08-22 03:00" --until "2026-08-22 04:00"
journalctl -u nginx -u php-fpm            # several services at once
journalctl _PID=1432                      # by specific process
journalctl -k                             # only kernel messages
journalctl -u sshd | grep "Failed password" | tail -20

grep と組み合わせますが、忘れないでください。--no-pager を付けない journalctl はページャーを開くので、q で終了します。

ジャーナルがディスクを食いつぶさないようにする

デフォルトでは、ジャーナルはパーティションの 10% まで増加します。40 GB のディスクを搭載した VDS-1 では、それが 4 ギガバイトになります――見過ごせません。

journalctl --disk-usage
journalctl --vacuum-size=200M
journalctl --vacuum-time=14d

恒久的な制限は /etc/systemd/journald.conf にあります。

[Journal]
SystemMaxUse=300M
MaxRetentionSec=1month

その後、systemctl restart systemd-journald を実行します。

よくある間違い

  • -u を付けずにジャーナルを読む。 全体のストリームはサービスの記録で埋め尽くされ、必要な行が埋もれてしまいます。常にサービスかレベルで絞り込んでください。
  • 再起動後に履歴を失う。 /var/log/journal ディレクトリが存在しない場合、ジャーナルはメモリ内にしか存在しません。作成してください: mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal。
  • そこでアプリケーションのエラーを探す。 Nginx、PostgreSQL なども /var/log 内の独自のファイルに書き込みます。ジャーナルが空なら、そちらを確認してください。

ディスクが満杯になると、空き容量が確保されるまで journalctl が動作を拒否することがあります。この状況はディスク容量不足の記事で扱っています。