journalctlチートシート：Linuxログの表示、絞り込み、ライブ追跡

journalctlを一行でまとめると、journalctl -u <service> -fで稼働中サービスのログを追跡、journalctl -u <service> -n 100で直近100行を表示、journalctl --since "1 hour ago"で最近のログを一括確認。「なぜこのサービスが落ちている？」の9割はこの3本で片付きます。このチートシートの残りは、真夜中にmanページを読み返すはめになる前に貼っておきたいコピペパターン集です——unit、時間、優先度、ブートでの絞り込みに加え、ジャーナルがディスクを食い尽くすのを止める掃除コマンドまで。以下のコマンドはすべて、systemdを採用するディストリビューション（Ubuntu、Debian、Fedora、Arch）でそのまま動きます。

journalctlとは何か？なぜ/var/log/syslogをそのまま読まないのか？

古いスタイルのLinuxロギングは、/var/log以下にsyslog、auth.log、messagesといったプレーンテキストを書き出していました。systemdはこれをジャーナルに置き換えます。systemd-journaldが管理する、バイナリ形式のインデックス付きログです。素のgrepでは読めず、journalctlが唯一の正面玄関。引き換えに、サービス・時間・ブート・重要度での絞り込みが正規表現の芸当なしで可能になります。

心のモデルは単純です。ジャーナルはすべてを保存し、journalctlはその問い合わせツール。サービスは独自のログファイルを必要としません。systemd下で動いている限り、stdout/stderrに書いたものはすべて自動的にジャーナルへ落ちます。nginxがエラーログをどこに設定しているのか知らなくてもjournalctl -u nginxが動くのは、このためです。

ひとつ注意点。ミニマルなインストールでは/var/log/journalが存在しないため、ジャーナルが揮発性（/runに保存され、再起動で消える）になっていることがあります。一度だけ直しておきましょう：

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

ログの直近100行だけ見るには？

-nは出力を最新のN行に制限します（デフォルトは10行）：

journalctl -n 100                      # すべてのログの直近100行
journalctl -u nginx -n 100             # 特定unitの直近100行
journalctl -n 100 --no-pager           # 表示して終了——パイプに最適

--no-pagerは見た目以上に重要です。付けないとjournalctlがlessを開き、スクリプトやパイプ、sshのワンライナーがキー入力待ちで固まります。出力をパイプで渡すコマンドには必ず付けましょう。

tail -fのようにログをライブ追跡するには？

-fフラグはjournalctl版のtail -fです。新しいエントリを随時ストリーミングします：

journalctl -f                    # すべてのログをライブ表示
journalctl -u sshd -f            # SSHデーモンだけをライブ表示
journalctl -u ollama -f -n 50    # ライブ表示、ただし直近50行から開始

サービスを再起動しながらもう一方の端末で眺める、という使い方が定石です。片方のペインでsystemctl restart nginx、もう片方でjournalctl -u nginx -f——クラッシュの原因はたいてい数秒で名乗りを上げます。homelabでも、コンテナやサービスが暴れたときは毎回このループを回しています。

特定サービスのログだけ表示するには？

-uはsystemd unitで絞り込みます：

journalctl -u nginx                    # 1つのunit、全履歴
journalctl -u nginx -u redis           # 複数unitを同時に
journalctl _SYSTEMD_UNIT=nginx.service # 完全一致の代替

unitは補助的なunitを派生させることがあり、そちらに重要な出力が残る場合があります。落ちているWebアプリが、本当のエラーを別のunit配下に記録していることは珍しくありません。-u <service>が何も返さないのにサービスは明らかに動いている——そんなときは、先に実際のunit名を特定しましょう：

systemctl list-units --type=service | grep -i <guess>

同じ-uパターンはタイマー（名前はsystemctl list-timersで確認）やユーザーサービスにも使えます。systemd --user配下で動くものには--userを付けます：

journalctl --user -u pipewire -n 50

ログを時間で絞り込むには？

--sinceと--untilはタイムスタンプを受け付けますが、寛容な相対表現も通ります：

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

時間窓とunitを組み合わせれば、インシデントの切り分けが1行で済みます。「APIは9時から落ちるまでの間に何を記録していたのか？」1台のマシンなら、どのログアグリゲータより速いはずです。

エラー（や警告）だけを表示するには？

-pは優先度で絞り込みます。syslogの重要度名を使います：

journalctl -p err -b              # 今回のブート中以降のエラーのみ
journalctl -p warning..alert -u nginx   # 重要度の範囲指定

優先度は高い順にemerg、alert、crit、err、warning、notice、info、debug。マシンの挙動が「おかしい」とき、journalctl -p err -b --since todayが最速の正気チェックです。「実際に何か失敗しているのか？」を、日常的なinfo行のノイズなしで答えてくれます。

前回ブート時のログを見るには？

起動時に落ちるサービスは、今回のブートより前のログ行を残しています。ところがjournalctlはデフォルトでは現行ブートしか表示しません。-bがブートを選択します：

journalctl -b                 # 今回のブートのみ
journalctl -b -1              # 前回のブート
journalctl -b -1 -u sshd      # 前回SSHが死んだ理由
journalctl --list-boots       # 保存されているブートの一覧

「壊れて、再起動して、もうエラーが見えない」というシナリオで最も有用なフラグがこれ。エラーは消えていません。1つ前のブートに残っています。

クイックリファレンス：覚えておきたいフラグ

目的	コマンド
サービスをライブ追跡	journalctl -u <svc> -f
直近100行	journalctl -n 100
1時間前から	journalctl --since "1 hour ago"
今回のブートのエラー	journalctl -p err -b
前回のブート	journalctl -b -1
ジャーナルのディスク使用量	journalctl --disk-usage
機械可読な出力	journalctl -o json-pretty
カーネルメッセージのみ	journalctl -k

ジャーナルでディスクが埋まるのを防ぐには？

まず使用量を確認し、それから上限を設定します：

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # 最新500MBを保持
sudo journalctl --vacuum-time=30d      # 最新30日を保持

恒久化するには、/etc/systemd/journald.confの[Journal]セクションにSystemMaxUse=500Mを設定し、sudo systemctl restart systemd-journaldを実行します。サイズ上限と前述のブートフィルタの合わせ技で、ジャーナルは「緩やかなディスクリーク」から道具に戻ります。

journalctl vs dmesg vs /var/log——最初にどこを見るべきか？

• journalctl — アプリケーションとサービスの挙動。systemdが管理するものはすべて、インデックス付きでフィルタ可能な形でここに入ります。まずここ、が基本の一手。
• journalctl -k / dmesg — カーネルとハードウェア。OOM kill、USBリセット、ディスクエラー。プロセスが原因不明で死んだときは、アプリを疑う前にここでOOMキラーを探しましょう。
• /var/log/<app>/ — 独自にファイルロギングするアプリ専用（nginxのアクセスログ、PostgreSQL）。とはいえ起動時のエラーは、たいていジャーナルにも流れます。

同じワークフローはローカルAIサービスにもそのまま広がります。ollama serveのunitが固まったとき、journalctl -u ollama -n 100はモデルロードの失敗を即座に見せてくれます。詳細はOllama vs LM Studio比較で扱っています。

以上がチートシートの全体像です。-uでunit、-fで追跡、-nで行数、--sinceで時間、-pで重要度、-bでブート。6つのフラグで、Linuxマシンが投げてくるログの質問はほぼ全部に答えられます。