journalctlの使い方 オプション早見表とログ削除・容量管理

journalctlとは、systemdのログ保管係であるsystemd-journaldが集めたログ（ジャーナル）を、検索・表示・削除するためのコマンドです。 サービス名で絞る -u、流れるログを追いかける -f、時間で区切る --since、重要度で絞る -p を組み合わせれば、数十万行のログから目的の数行だけをすぐに取り出せます。

この記事では、やりたいことからコマンドを引ける逆引き表を先頭に置き、それぞれのコマンドについて実際に出力された文字列を載せています。後半では --disk-usage で容量を調べるところから、--vacuum-size と --vacuum-time での削除、journald.conf の SystemMaxUse・Storage による上限設定までを一連の手順で確かめます。Ubuntu/Debian系とRHEL系の違い、「No journal files were found」や権限不足のメッセージが出たときの対処もまとめました。

journalctlの早見表（やりたいこと→コマンド）

この記事で確かめた環境と出力の読み方

出力はすべて Ubuntu 24.04.4 LTS（systemd 255.4）で実際に実行したものです。確かめ方は次の2通りです。

記事中のコマンドは読みやすさのため -D と --no-pager を省いて書いています。ふだんのサーバーでは、書いてあるとおりに打てば同じ形の出力になります。 systemctl restart を使う手順と RHEL 系での動作は今回動かしていないため、該当箇所に「未実行」と書いています。

journalctlの基本：まず覚える4つの使い方

最新のログを見る（-n と -e）

オプションなしの journalctl は、保存されている一番前のログから表示します。調査では新しいほうから見ることが多いので、まず -n 行数 か -e を付けるのが近道です。

journalctl -n 5

Oct 03 09:40:09 web01 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Oct 03 09:40:09 web01 systemd[1]: myapp.service: Failed with result 'exit-code'.
Oct 03 09:41:30 web01 nginx[690]: 2026/10/03 09:41:30 [error] 690#690: *12 connect() failed (111: Connection refused) while connecting to upstream
Oct 03 09:50:00 web01 systemd[1]: Started myapp.service - My App.
Oct 03 09:50:01 web01 myapp[1502]: listening on port 8080

1行は「日時 ホスト名 プログラム名[プロセスID]: メッセージ」の順に並びます。systemd[1] はサービスの起動や停止を記録した行、myapp[1502] はアプリ自身が出した行です。

サービス単位で見る（-u）

journalctl -u myapp.service

Oct 02 14:12:40 web01 myapp[812]: slow query: 1532 ms (GET /orders)
Oct 02 23:59:50 web01 systemd[1]: Stopped myapp.service - My App.
-- Boot 9a8b7c6d5e4f40312a1b0c9d8e7f6a5b --
Oct 03 08:00:07 web01 systemd[1]: Started myapp.service - My App.
Oct 03 08:00:08 web01 myapp[745]: listening on port 8080
Oct 03 09:40:03 web01 myapp[745]: retrying connection to db (attempt 2)
Oct 03 09:40:09 web01 myapp[745]: database connection refused: 127.0.0.1:5432
Oct 03 09:40:09 web01 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Oct 03 09:40:09 web01 systemd[1]: myapp.service: Failed with result 'exit-code'.
Oct 03 09:50:00 web01 systemd[1]: Started myapp.service - My App.
Oct 03 09:50:01 web01 myapp[1502]: listening on port 8080

-- Boot ... -- の行は、そこで再起動があった印です。-u myapp のように .service を省いても同じ結果になります。-u を2つ並べると「どちらかに当てはまるもの」になり、関係するサービスを時系列でまとめて見られます（後述）。

流れるログを追いかける（-f）

journalctl -u myapp -f

-f は直近の10行を出したあと、新しいログが届くたびに1行ずつ表示し続けます。別の端末からログを1件書き込むと、次のように即座に現れました（-n 0 を付けて過去分を出さないようにした例です）。

# 端末A
journalctl -f -n 0 -t demo
# 端末B
echo "live line" | systemd-cat -t demo

Oct 03 17:32:41 vm demo[1017]: live line

systemd-cat は標準入力や任意のコマンドの出力をジャーナルに書き込む道具です。自作スクリプトのログを journalctl で読めるようにしたいときにも使えます。

時間で絞る（--since と --until）

journalctl -u myapp --since "2026-10-03 09:40" --until "2026-10-03 09:45"

Oct 03 09:40:03 web01 myapp[745]: retrying connection to db (attempt 2)
Oct 03 09:40:09 web01 myapp[745]: database connection refused: 127.0.0.1:5432
Oct 03 09:40:09 web01 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Oct 03 09:40:09 web01 systemd[1]: myapp.service: Failed with result 'exit-code'.

指定できる書き方は次のとおりです。

綴りを誤ると次のメッセージが返ります。空白を含む値は引用符で囲むのが確実です。

$ journalctl --since "yesterdayy"
Failed to parse timestamp: yesterdayy

重要度で絞る（-p）

-p はログの重要度（priority）で絞ります。指定したレベルと、それより重いものすべてが表示されます。

journalctl -p warning -b

Oct 03 08:00:02 web01 kernel: ACPI: \_SB_.PCI0: _OSC evaluation failed
Oct 03 09:40:03 web01 myapp[745]: retrying connection to db (attempt 2)
Oct 03 09:40:09 web01 myapp[745]: database connection refused: 127.0.0.1:5432
Oct 03 09:40:09 web01 systemd[1]: myapp.service: Failed with result 'exit-code'.
Oct 03 09:41:30 web01 nginx[690]: 2026/10/03 09:41:30 [error] 690#690: *12 connect() failed (111: Connection refused) while connecting to upstream

-p err に変えると warning の行が消え、err の行だけになります。-p 3..4 のように範囲でも書けます。存在しない名前を渡したときのメッセージは次のとおりです。

$ journalctl -p foo
Unknown log level foo

アプリが重要度を付けずに標準出力へ書いた行は info(6) として扱われます。 そのため -p err で何も出ないときは、アプリ側のログが info で届いている可能性があります。その場合は -p を外し、-g で文字列検索するほうが見つけやすくなります。

起動単位で見る（-b と --list-boots）とカーネルログ（-k）

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -1 1f0c3a7e5d2b4c6f8a9b0c1d2e3f4a5b Fri 2026-10-02 09:00:01 JST Fri 2026-10-02 23:59:50 JST
  0 9a8b7c6d5e4f40312a1b0c9d8e7f6a5b Sat 2026-10-03 08:00:01 JST Sat 2026-10-03 09:50:01 JST

IDX の 0 が今回の起動、-1 が1つ前です。再起動の直前に何が起きたかを見るなら -b -1 を使います。

journalctl -b -1 -n 3

Oct 02 14:12:40 web01 myapp[812]: slow query: 1532 ms (GET /orders)
Oct 02 18:30:11 web01 kernel: EXT4-fs error (device sdb1): ext4_find_entry:1678: inode #2: comm ls: reading directory lblock 0
Oct 02 23:59:50 web01 systemd[1]: Stopped myapp.service - My App.

-k はカーネルが出したログだけを表示します。-b と組み合わせて「今回の起動のカーネルログ」を見る形がよく使われます。

journalctl -k -b

Oct 03 08:00:01 web01 kernel: Linux version 6.8.0-45-generic (buildd@lcy02-amd64-075)
Oct 03 08:00:02 web01 kernel: ACPI: \_SB_.PCI0: _OSC evaluation failed

保存されていない起動番号を指定すると、次のメッセージになります。

$ journalctl -b -5
No journal boot entry found from the specified boot offset (-5).

出力形式を変える（-o json ほか）

journalctl -u myapp -n 2 -o short-iso

2026-10-03T09:50:00+09:00 web01 systemd[1]: Started myapp.service - My App.
2026-10-03T09:50:01+09:00 web01 myapp[1502]: listening on port 8080

journalctl -u myapp -n 2 -o cat

Started myapp.service - My App.
listening on port 8080

journalctl -u myapp -n 1 -o json-pretty

{
    "_UID" : "0",
    "__CURSOR" : "s=04d45ada89cb401c8abc83c82355251c;i=13;b=9a8b7c6d5e4f40312a1b0c9d8e7f6a5b;m=189734440;t=65ce5075c0040;x=6cfe014133ff0d3",
    "_MACHINE_ID" : "0123456789abcdef0123456789abcdef",
    "_COMM" : "myapp",
    "__SEQNUM_ID" : "04d45ada89cb401c8abc83c82355251c",
    "__SEQNUM" : "19",
    "_HOSTNAME" : "web01",
    "MESSAGE" : "listening on port 8080",
    "_PID" : "1502",
    "__REALTIME_TIMESTAMP" : "1790988601000000",
    "__MONOTONIC_TIMESTAMP" : "6601000000",
    "_TRANSPORT" : "journal",
    "PRIORITY" : "6",
    "_SYSTEMD_UNIT" : "myapp.service",
    "SYSLOG_IDENTIFIER" : "myapp",
    "_BOOT_ID" : "9a8b7c6d5e4f40312a1b0c9d8e7f6a5b"
}

JSONを見ると、ジャーナルの1件が「項目名と値の集まり」であることがわかります。-u は _SYSTEMD_UNIT、-p は PRIORITY、-t は SYSLOG_IDENTIFIER、-b は _BOOT_ID を見ている、と対応づけると、オプションの意味がつかみやすくなります。__REALTIME_TIMESTAMP は1970年からのマイクロ秒で、数値も文字列として出力される点に気をつけます。

項目名を直接書いて絞ることもできます。

journalctl _PID=745

Oct 03 08:00:08 web01 myapp[745]: listening on port 8080
Oct 03 09:40:03 web01 myapp[745]: retrying connection to db (attempt 2)
Oct 03 09:40:09 web01 myapp[745]: database connection refused: 127.0.0.1:5432

記録されているユニット名の一覧は -F で取り出せます。-u に渡す名前がわからないときに便利です。

$ journalctl -F _SYSTEMD_UNIT
ssh.service
myapp.service
nginx.service

オプションを組み合わせる逆引き（実際の出力つき）

journalctl のオプションは、種類の違うもの同士は「かつ」、同じ種類を並べると「または」として働きます。この規則を知っておくと、組み合わせを自分で作れます。

journalctl -u nginx -u myapp -p err -b

Oct 03 09:40:09 web01 myapp[745]: database connection refused: 127.0.0.1:5432
Oct 03 09:41:30 web01 nginx[690]: 2026/10/03 09:41:30 [error] 690#690: *12 connect() failed (111: Connection refused) while connecting to upstream

アプリがDBにつながらなくなり、その約80秒後に nginx 側でも接続エラーが出た、という流れが2行で読み取れます。原因と結果を1つの時系列に並べられるのが、-u を複数並べる利点です。

journalctl -g "refused"

-- Boot 9a8b7c6d5e4f40312a1b0c9d8e7f6a5b --
Oct 03 09:40:09 web01 myapp[745]: database connection refused: 127.0.0.1:5432
Oct 03 09:41:30 web01 nginx[690]: 2026/10/03 09:41:30 [error] 690#690: *12 connect() failed (111: Connection refused) while connecting to upstream

-g に小文字だけを渡すと大文字小文字を区別せずに探すため、nginx の「Connection refused」も一致しています。

journalctl -p 3..4 -b -u myapp

Oct 03 09:40:03 web01 myapp[745]: retrying connection to db (attempt 2)
Oct 03 09:40:09 web01 myapp[745]: database connection refused: 127.0.0.1:5432
Oct 03 09:40:09 web01 systemd[1]: myapp.service: Failed with result 'exit-code'.

サービスが起動しないときの定番は、次の2つを順に実行する形です（systemctl は今回未実行です）。

systemctl status myapp        # 状態と直近の数行
journalctl -u myapp -b -e     # 今回の起動分を末尾から

journalctl -xe もよく紹介されます。-x は一部のメッセージに説明文を添えるオプション、-e は末尾へ移動するオプションです。全サービスのログが混ざるので、対象が決まっているなら -u を足すと読みやすくなります。

ログの容量を調べて削除する手順

ここからは、ジャーナルがディスクを使いすぎているときの対処を順番に進めます。検証用の領域で約12万件（1件およそ900バイト）のログを書き込み、その状態から始めます。

手順1：使用量を調べる（--disk-usage）

journalctl --disk-usage

Archived and active journals take up 71.9M in the file system.

実体は /var/log/journal/マシンID/ の下にあります。

$ ls -la /var/log/journal/*/
-rw-r----- 1 root systemd-journal 16777216 Oct  3 17:32 system.journal
-rw-r----- 1 root systemd-journal 25165824 Oct  3 17:32 system@4b2997c0...-0000000000000174-00065ceb7dc43b9e.journal
-rw-r----- 1 root systemd-journal 25165824 Oct  3 17:32 system@4b2997c0...-0000000000008761-00065ceb7e55c39b.journal
-rw-r----- 1 root systemd-journal 25165824 Oct  3 17:32 system@4b2997c0...-0000000000010d3e-00065ceb7e897afe.journal

（ファイル名は途中を省略しています。）system.journal が今書き込み中のファイル（アクティブ）、system@...journal が書き終えたファイル（アーカイブ）です。この区別が次の手順で効いてきます。

手順2：書き込み中のファイルを区切る（--rotate）

--vacuum-* が削除するのはアーカイブ済みのファイルだけです。書き込み中のファイルも対象に含めたいときは、先に --rotate で区切ります。

sudo journalctl --rotate

実行すると、それまでの system.journal が system@...journal に名前を変え、新しい system.journal（8MB）が作られました。

手順3：サイズを指定して削除する（--vacuum-size）

sudo journalctl --vacuum-size=50M

Deleted archived journal /var/log/journal/c1d60f590676409fadd11ab338e333b8/system@4b2997c01c1640458c3fb1aae5b65d26-0000000000000174-00065ceb7dc43b9e.journal (18.6M).
Deleted archived journal /var/log/journal/c1d60f590676409fadd11ab338e333b8/system@4b2997c01c1640458c3fb1aae5b65d26-0000000000008761-00065ceb7e55c39b.journal (18.6M).
Vacuuming done, freed 37.2M of archived journals from /var/log/journal/c1d60f590676409fadd11ab338e333b8.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal.

$ journalctl --disk-usage
Archived and active journals take up 35.9M in the file system.

50M を指定して、結果は 35.9M になりました。削除はファイル単位で前のものから行われるため、指定値ちょうどではなく「指定値以下になるところまで」減ります。 行単位で消す機能はなく、特定のサービスのログだけを消すこともできません。

手順4：期間を指定して削除する（--vacuum-time）

sudo journalctl --vacuum-time=2weeks

「2週間より前のログだけを含むアーカイブ」を削除します。検証では結果を見やすくするために 1s を指定し、直前に --rotate を実行しました。

$ sudo journalctl --rotate
$ sudo journalctl --vacuum-time=1s
Deleted archived journal /var/log/journal/c1d6.../system@4b29...-0000000000010d3e-00065ceb7e897afe.journal (18.6M).
Deleted archived journal /var/log/journal/c1d6.../system@4b29...-0000000000019323-00065ceb7ebcf46d.journal (9.3M).
Deleted archived journal /var/log/journal/c1d6.../system@4b29...-000000000001d7ad-00065ceb7ef81d5c.journal (1.4M).
Vacuuming done, freed 29.3M of archived journals from /var/log/journal/c1d60f590676409fadd11ab338e333b8.
$ journalctl --disk-usage
Archived and active journals take up 8.0M in the file system.

（パスは途中を省略しています。）アーカイブがすべて消えても 8.0M が残ります。これは書き込み中の system.journal の分で、journald が動いている限り存在します。「全部消したのに 0 にならない」と感じたときは、この仕組みを思い出してください。

sudo journalctl --rotate --vacuum-time=2weeks のように1行で書くこともできます。/var/log/journal の中のファイルを rm で直接消す方法は、journald が開いているファイルを消すことになるため、--vacuum-* を使うほうが安心です。

journald.confで上限を決めて自動で保つ

手作業の削除は一度きりです。上限を設定しておけば、journald が自動で前のファイルから削除して範囲内に保ちます。

設定ファイルの場所と書き方

Ubuntu 24.04 の /etc/systemd/journald.conf は、すべての行が # で始まっています。これは「組み込みの既定値の一覧」で、変更したい項目だけを別ファイルに書くのがおすすめです。

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/size.conf <<'EOF'
[Journal]
SystemMaxUse=500M
SystemMaxFileSize=50M
MaxRetentionSec=1month
EOF
sudo systemctl restart systemd-journald

journald.conf.d/ に置いた .conf は本体の設定に上書きで適用されるため、パッケージ更新で本体が置き換わっても自分の設定が残ります。今の設定全体は systemd-analyze cat-config systemd/journald.conf で確認できます。

上限が効くことを確かめる

SystemMaxUse=30M、SystemMaxFileSize=8M を設定して journald を起動し直すと、起動時のログに上限が表示されました（検証環境では systemctl が使えないため、journald のプロセスを直接起動し直しています。systemctl restart systemd-journald は未実行です）。

Oct 03 17:33:00 vm systemd-journald[1667]: Journal started
Oct 03 17:33:00 vm systemd-journald[1667]: System Journal (/var/log/journal/c1d60f590676409fadd11ab338e333b8) is 8.0M, max 30.0M, 22.0M free.

この状態で再び約12万件を書き込んだ結果です。

$ journalctl --disk-usage
Archived and active journals take up 24.3M in the file system.
$ du -sh /var/log/journal
25M /var/log/journal

設定前は同じ量で 71.9M まで増えていましたが、設定後は 30M の範囲に収まり、ファイルも8MBごとに区切られました。現在の上限は journalctl -u systemd-journald で max の値を見れば確かめられます。

主な設定項目

既定値は、手元の journald.conf のコメントと、今回開いた journald.conf(5) の man ページ（man7.org 掲載版）で確認した内容です。

Storage=auto は「/var/log/journal ディレクトリがあればディスクに保存、なければ /run/log/journal（メモリ上）に保存」という動作です。今回開いた man ページ（systemd 262 の開発版の文書）では既定が persistent と書かれており、systemd の版によって既定が異なります。手元の journald.conf のコメントを見るのが確実です。

Storage=volatile を設定して起動し直すと、新しいログは /run/log/journal/ に書かれることを確かめました。

$ ls /run/log/journal/*/
system.journal

定期的に削除したいとき

多くの場合は SystemMaxUse と MaxRetentionSec の設定だけで足ります。設定ファイルを変えずに日次で整理したい場合は、cron に1行足す方法もあります（次の例は未実行です）。

# /etc/cron.d/journal-vacuum（毎日 3:30 に2週間より前を削除）
30 3 * * * root /usr/bin/journalctl --rotate --vacuum-time=2weeks

Ubuntu/Debian系とRHEL系の違い

Ubuntu 24.04 については今回確認した内容、RHEL 系については一般に知られた仕様（今回は未実行）です。手元の環境では、表の「確かめ方」のコマンドで実際の状態を見てください。

Ubuntu 24.04 で確認した ACL は次のとおりで、adm グループに読み取りが付いています。

$ getfacl /var/log/journal
# owner: root
# group: systemd-journal
user::rwx
group::r-x
group:adm:r-x

「再起動したらログが消えていた」ときは、保存先がメモリ上になっていることが考えられます。次の手順でディスク保存に切り替えられます（systemd-tmpfiles と systemctl の部分は未実行です）。

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

ログが出ないときの対処

「No journal files were found.」と表示される

ジャーナルファイルが1つも見つからないときのメッセージです。今回の検証環境（journald が動いていないコンテナ）で、実際に次のように表示されました。

$ journalctl -n 3
No journal files were found.
-- No entries --
$ journalctl --disk-usage
No journal files were found.
Archived and active journals take up 0B in the file system.

権限が足りないときのメッセージ

一般ユーザーで実行すると、次の表示になることがあります。

$ journalctl -n 2
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
No journal files were opened due to insufficient permissions.

対処は2通りです。

# その場で読む
sudo journalctl -u myapp -n 50

# 毎回 sudo を付けずに読めるようにする（一度ログアウトして入り直すと有効になる）
sudo usermod -aG systemd-journal taro

（ユーザー名は例です。usermod は今回未実行です。）なお、--vacuum-* や --rotate はファイルを変更する操作なので、グループに入っていても sudo が必要です。

-u で何も出ないとき

ユニット名が違っていてもエラーにはならず、-- No entries -- だけが返ります。

$ journalctl -u x
-- No entries --

よくある質問

Q. journalctl と /var/log/syslog（または /var/log/messages）はどう使い分けますか？ A. 内容は多くが重なります。サービス名・時間・重要度で絞りたいときは journalctl、grep や既存のログ収集の仕組みで扱いたいときはテキストのログが向いています。ジャーナルは容量の上限で前のものから消えるため、長期保存が必要なログは別の仕組みに転送しておくと安心です。

Q. --vacuum-size を実行しても容量があまり減りません。なぜですか？ A. 削除されるのはアーカイブ済みのファイルだけで、書き込み中の system.journal は残るためです。sudo journalctl --rotate --vacuum-size=100M のように --rotate を先に付けると、直前までの分も削除の対象になります。

Q. 特定のサービスのログだけを削除できますか？ A. できません。削除はファイル単位で、1つのファイルに複数のサービスのログが混ざって入っています。見たくないサービスがあるときは、削除ではなく -u で表示側を絞ります。

Q. ページャー（less）で開かれるのを止めたいです。 A. --no-pager を付けます。パイプやリダイレクトにつないだ場合は自動でページャーなしになります。長い行が右で切れて見えるときは、ページャーの中で矢印キーの右を押すか、--no-pager で折り返して表示します。

まとめ

• まず -u サービス名、-n 行数、-f、--since の4つを覚えると、日常の確認はほぼ足ります。
• 種類の違うオプションは「かつ」、同じオプションを並べると「または」。-u nginx -u myapp -p err -b で関係するサービスのエラーを時系列に並べられます。
• -o json と -o cat で取り出し方を変えられます。 -u は _SYSTEMD_UNIT、-p は PRIORITY を見ています。
• 容量は --disk-usage で調べ、--rotate のあと --vacuum-size か --vacuum-time で削除します。削除はアーカイブ単位で、書き込み中のファイルは残ります。
• 恒久的な対策は journald.conf.d/ に SystemMaxUse= を書くこと。 30M に設定した検証では、同じ量を書き込んでも 24.3M に収まりました。
• Ubuntu 24.04 は最初からディスクに保存されます。再起動でログが消える環境では /var/log/journal の有無を確かめます。
• 「No journal files were found」は保存先と journald の状態、権限のメッセージは systemd-journal グループを確認します。

参考・出典

• journald.conf(5) man ページ（man7.org 掲載版。今回開いて既定値を確認）
• Ubuntu 24.04.4 LTS に含まれる /etc/systemd/journald.conf と /usr/lib/systemd/journald.conf.d/syslog.conf（systemd 255.4）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。