Linuxでjournalctlを知らずにsystemdのログが見つからないと3時間格闘した話｜現役講師が語るrsyslogからjournalへの移行で変わったログ調査の習慣

ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux学習ガイド ＞ Linuxでjournalctlを知らずにsystemdのログが見つからないと3時間格闘した話｜現役講師が語るrsyslogからjournalへの移行で変わったログ調査の習慣
宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「/var/log/messagesをgrepしても何も出てこない。このサーバー、ログが記録されていないんでしょうか」

セミナーの質疑応答でそう聞かれた時、私は少し動揺しました。
CentOS 7が普及して数年が経つ頃のことでしたが、私自身まだ journalctl を体系的に使えていなかったからです。

この記事では、RHEL 7 / CentOS 7世代から始まったsystemdへの移行で起きた「ログの場所と見方の変化」と、journalctl を現場で使いこなすまでの経験を、20年以上Linuxサーバーを運用してきた立場から解説します。
現在のRHEL 9 / AlmaLinux 9 / Ubuntu 24.04 LTSでも journalctl は主力のログ調査コマンドです。いまも /var/log/messages だけに頼っているなら、ぜひ最後まで読んでください。

この記事のポイント

・RHEL 7以降でsystemdに変わりログの保存先と見方が大きく変わった
・journalctl -u でサービス単位、--since で時間範囲を絞り込める
・起動時のログは journalctl -b で遡れる（/var/log/messagesでは不可）
・rsyslogとjournaldは共存可能。目的に合わせて使い分けるのが実務の作法


Linuxでjournalctlを知らずにsystemdのログが見つからないと3時間格闘した話｜現役講師が語るrsyslogからjournalへの移行で変わったログ調査の習慣
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

「/var/log/messagesがない」が意味すること

CentOS 6以前の世界では、サーバーのログは rsyslog（または syslog）というデーモンが管理していました。ログファイルは /var/log/messages、/var/log/secure、/var/log/maillog といったテキストファイルとして生成され、grep、tail -f、less で自由に読めました。

CentOS 7（2014年6月リリース）からsystemdが標準の初期化システムになったとき、ログ管理の仕組みも大きく変わりました。systemd-journald（ジャーナルd）という新しいデーモンが、syslogの役割の多くを引き受けるようになったのです。

「/var/log/messagesが見つからない」と受講生が言っていたのは、まさにこの変化のためです。systemdのデフォルト設定では、ログは /run/log/journal/ か /var/log/journal/ というバイナリ形式のディレクトリに保存されます。このファイルはテキストではないため、cat や grep では直接読めません。

私がセミナーで長年使っていたデモ環境はCentOS 6ベースでした。受講生は最新のCentOS 7環境で手を動かしていた。その差に気づかないまま「/var/log/messagesを開いてください」と案内していたのです。20年以上サーバーを運用してきた経験から言うと、こういった「自分が慣れたやり方を疑わない」時期が、技術者にとって一番危険な状態です。慣れ親しんだ手順ほど、変化を見逃しやすい。

journalctlを知らずに格闘した3時間の話

セミナー後に自分の手元のCentOS 7環境で試してみると、確かに /var/log/messages はデフォルトでは存在しませんでした。rsyslogをインストールすれば復活しますが、OSのクリーンインストール直後の状態では見当たらない。

最初の私の対処は「受講生の環境にrsyslogをインストールしてもらう」でした。慣れたコマンドで授業を進めることを優先したわけです。しかし、それでいいとは思えなかった。「新しい仕組みが普及しているのに旧来の方法に引き戻している」という後ろめたさが残りました。

その夜、3時間ほどかけて journalctl のmanページとRed Hatの公式ドキュメントを読み込みました。読み終えてわかったのは、これが「rsyslogの単なる代替」ではなく、大幅に進化したログ管理の仕組みだということでした。

最も驚いたのは、システム起動時のログまで遡れることでした。rsyslogが動き出す前、カーネルの初期化メッセージまで journalctl -b で確認できる。従来の /var/log/messages ではここまで追えませんでした。fstabの設定ミスでサーバーが起動しない、といった障害でその強さが発揮されます。

もうひとつ大きな違いは、サービス単位でのフィルタリングが直感的になったことです。「httpdのログだけ見たい」という場面で、以前は grep httpd /var/log/messages のように工夫が必要でしたが、journalctl -u httpd の一発で済む。

「なぜ最初からこちらを教えてこなかったのか」と自分を責めた夜でした。受講生の質問がなければ、私はまだrsyslogの世界だけで教え続けていたかもしれません。指摘してくれた受講生に感謝しつつ、翌週のセミナーからは journalctl を正式なカリキュラムに組み込みました。

journalctlの基本的な使い方

1. ログを表示する — まず覚えるコマンド

最低限これだけ覚えれば現場で使えます。RHEL 9 / AlmaLinux 9 / Ubuntu 24.04 LTSで動作確認済みです。

# 最新100行のログを表示
# journalctl -n 100

# ログをリアルタイムで追う（tail -f と同じ感覚で使える）
# journalctl -f

# 特定サービスのログだけ表示（httpd の例）
# journalctl -u httpd

# エラー以上の優先度のログだけ表示（emerg/alert/crit/err が対象）
# journalctl -p err
実行例（AlmaLinux 9 で journalctl -u httpd -n 20 を実行した出力）:

-- Logs begin at Mon 2024-09-02 09:00:01 JST, end at Mon 2024-09-02 14:32:11 JST. --
Sep 02 14:20:33 web01.example.com httpd[2341]: AH00557: httpd: apr_sockaddr_info_get() failed for web01
Sep 02 14:20:33 web01.example.com httpd[2341]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1
Sep 02 14:22:15 web01.example.com systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
Sep 02 14:22:15 web01.example.com systemd[1]: httpd.service: Failed with result 'exit-code'.
Sep 02 14:22:15 web01.example.com systemd[1]: Failed to start The Apache HTTP Server.
この出力の読み方がわかると、障害調査の速度が大きく変わります。httpd[2341] の部分はプロセスID（PID）です。同じPIDのログを追うことで、一連のイベントの流れが把握できます。AH00558 のようなエラーコードをそのままWebで検索すると、公式ドキュメントや解決策にたどり着けます。セミナーでは「エラーコードをGoogleに貼る」これだけで解決する障害が意外と多いと伝えています。

2. 時間範囲を絞ってログを調査する

障害発生時刻がわかっている場合、時間でフィルタリングするとノイズを大幅に減らせます。私がセミナーで「障害調査の最初の1手」として必ず教えている手順です。

# 今日のログだけ表示
# journalctl --since today

# 昨日のログを表示
# journalctl --since yesterday --until today

# 時間範囲を指定（障害発生前後2時間を調べる例）
# journalctl --since "2024-09-02 13:00:00" --until "2024-09-02 15:00:00"

# 特定サービス＋時間範囲の組み合わせ（実務での定番）
# journalctl -u httpd --since "2024-09-02 13:00:00" --until "2024-09-02 15:00:00"
セミナーで受講生からよく聞かれるのが「tail -f で流れた前のログはどうやって見るのか」という質問です。journalctl --since と --until を組み合わせれば、ページャー（lessと同じ操作）で静的に確認できます。特定の時間帯を落ち着いて読みたい場面で重宝します。「いつ何が起きたか」を時系列で整理することが、障害原因の特定を大幅に速めます。

3. 起動時のログを確認する

サーバーが正常に起動しなかった場合、一番役立つのが -b オプションです。

# 今回の起動分のログを表示
# journalctl -b

# ひとつ前の起動分のログを表示（再起動後の事後確認に使う）
# journalctl -b -1

# 過去の起動一覧を確認（いつ・何回起動したかがわかる）
# journalctl --list-boots
fstabの設定ミスでサーバーが起動しなかった経験のある方はわかると思いますが、従来の /var/log/messages はrsyslogが動き出してからしか記録を始めません。journalctl -b はそれより前、カーネルの初期化メッセージまで遡れるのが大きな強みです。

私が現場でよく見かけるのが、journalctl -b -1 を再起動直後に打って「前回の起動でどんなエラーが出ていたか」を確認する習慣を持っているエンジニアです。こういう小さな確認を欠かさない人が、長期にわたって安定した運用を続けられます。

journalctlでエラーが出た・うまく動かない時の対処法

現場でよくあるトラブルとその対処をまとめます。

「No journal files were found」が出る

systemd-journaldが動いていないか、ジャーナルの保存場所が存在しない場合に出ます。まずはデーモンの状態確認から始めましょう。

# journaldの動作確認
# systemctl status systemd-journald

# ジャーナルの保存先を確認（永続保存かどうか判断する）
# ls -la /var/log/journal/
# ls -la /run/log/journal/
永続保存されていない場合（/run/log/journal/ のみ存在する場合）、再起動するとログが消えます。永続保存を有効にするには /var/log/journal/ ディレクトリを作成するだけです。注意が必要なのは、永続保存を有効にするとディスク使用量が増える点です。

# ジャーナルの永続保存を有効にする（ディレクトリ作成後にjournaldを再起動する）
# mkdir -p /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald

ジャーナルのディスク使用量が大きくなっている

journaldはデフォルトでディスク空き容量の15%まで使います。気づかないうちにかさんでいることがあるので、定期的な確認が鉄則です。特に長期稼働のサーバーでは要注意です。

# ジャーナルのディスク使用量を確認
# journalctl --disk-usage

# 古いジャーナルを削除（2週間以上前のものを削除する例）
# journalctl --vacuum-time=2weeks

# ジャーナルのサイズを100MBに制限する
# journalctl --vacuum-size=100M
受講生からよく聞かれるのが「logrotateとの管理が重複しないか」という質問です。journaldはrsyslogとは別の仕組みで動いています。rsyslogへのログ転送が設定されている環境では、/var/log/messages のlogrotateと journalctl --vacuum-time を両方設定することになります。「journaldは自分の管轄」「/var/log/ 以下はlogrotateの管轄」と分けて考えると整理しやすいです。

rsyslogとjournaldが共存する環境でのログ調査の考え方

RHEL 9 / AlmaLinux 9でも、rsyslogはデフォルトでインストールされています。journaldのログをrsyslogに転送し、/var/log/messages や /var/log/secure も同時に生成される構成になっています。

つまり現場では「どちらで調査してもいい」状態が多いのですが、セミナーで3,100名以上を指導してきた経験から感じる使い分けの目安は次のとおりです。

・journalctlを優先する場面：systemdで管理されているサービスの起動失敗・クラッシュ調査。起動時のカーネルパニック調査。直近の短い時間範囲でのリアルタイム追跡。
・/var/log/messages をgrepする場面：長期間にわたるログのパターン検索。既存のシェルスクリプト（awkやsedとのパイプ処理）との連携。複数サーバーのログをまとめて集計する場合。

「どちらが正しい」ではなく「目的に合わせて使い分ける」が実務の考え方です。journalctlとrsyslogの両方を知っているエンジニアは、知らないエンジニアより障害調査の初動が確実に速い。私が両方を教えるようになってから、受講生の障害対応の習熟度が上がったと実感しています。

なお、systemctlとchkconfigの違いについての記事も合わせて読むと、サービス管理とログ調査の全体像がつかめます。Postfixのメールログ（/var/log/maillog または journalctl -u postfix）については、Postfixのバージョン確認と設定確認の記事で詳しく解説しています。

まとめ

journalctlは、systemd環境でのログ調査に欠かせないコマンドです。「/var/log/messagesに慣れていたから」という理由だけで使わないでいると、現場で確実に遅れをとります。

私自身がセミナーの受講生の質問がきっかけでようやく腰を上げた経験から言えば、「知らないと気づいた瞬間」が一番の学習チャンスです。基本コマンドを手元で1回打てば、後は実務の中でどんどん慣れていきます。今日から journalctl -f でリアルタイムのログ確認を習慣にするだけでも、障害対応の速さが変わってきます。
やりたいこと コマンド
最新100行のログを表示 journalctl -n 100
リアルタイムでログを追う journalctl -f
特定サービスのログを表示 journalctl -u サービス名
エラー以上のログを表示 journalctl -p err
今日のログを表示 journalctl --since today
時間範囲を指定して表示 journalctl --since "2024-01-01 10:00:00" --until "2024-01-01 12:00:00"
今回の起動分のログ journalctl -b
前回の起動分のログ journalctl -b -1
ジャーナルのディスク使用量確認 journalctl --disk-usage
古いジャーナルを削除 journalctl --vacuum-time=2weeks
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、journalctlをはじめとするサーバー障害調査の実践的な手順を、実機ハンズオンで体得するセミナーを開催しています。
＞＞ Linuxサーバー構築入門マニュアル（図解60P）を無料ダウンロードする

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。