Ubuntuでトラブルが起きたとき、最初にやることはログの確認です。結論からいうと、systemd環境では journalctl コマンドが最も強力な一次ツールで、加えて /var/log/syslog（rsyslog）と dmesg（カーネルログ）の3つを押さえておけば、ほとんどのトラブルは調査できます。
本記事では Ubuntu 24.04 LTS と Ubuntu 22.04 LTS の公式Dockerイメージを実際に起動し、各バージョンのsystemdとrsyslogのバージョン・設定ファイルの中身を確認した上で、コマンドの実出力をそのまま掲載しています。
この記事のポイント
- Ubuntu 24.04 LTS のsystemdは
255（rsyslogは8.2312.0）— バージョンは実測値 journalctl -n 50で直近50件、journalctl -fでリアルタイム表示journalctl -u nginx.service -p errでサービス別エラーだけ一発抽出- Ubuntu 24.04 は /var/log/journal/ が初期作成され、デフォルトで永続ログが有効
- コンテナ（Docker）では journalctl が使えない — VPS本番環境で初めて活きるコマンド
目次
前提環境
本記事のコマンドはすべて以下の環境で検証しています。
| 項目 | Ubuntu 24.04 LTS | Ubuntu 22.04 LTS |
|---|---|---|
| コードネーム | Noble Numbat | Jammy Jellyfish |
| systemd バージョン | 255（255.4-1ubuntu8.16） | 249（249.11-0ubuntu3.21） |
| rsyslog バージョン | 8.2312.0-3ubuntu9.2 | 8.2112.0-2ubuntu2.2 |
| dmesg（util-linux） | 2.39.3 | 2.37.2 |
| 検証環境 | Docker公式イメージ + VPS本番（systemd稼働確認） | |
| 検証日 | 2026年6月13日 | |
注意
Dockerコンテナ（docker run ubuntu:24.04）の中では、systemdが起動しないため journalctl は 「No journal files were found.」 を返します。journalctlが実際にログを表示するのはVPSや実機（systemdが動いている環境）です。本記事のコマンド例のうち、journalctlのログ出力部分はVPS実機での実行例です。
Ubuntuのログシステムを理解する
Ubuntu 20.04以降のシステムには、ログの仕組みが2系統あります。これを最初に整理しておくと、どのコマンドで何を確認するかが一気にクリアになります。
journaldとrsyslog — 2つのログシステム
systemd-journaldはsystemdに内蔵されたログ収集デーモンです。起動から全サービスのログをバイナリ形式で収集し、journalctl コマンドで柔軟に絞り込めます。
一方のrsyslogは伝統的なSyslogデーモンで、/var/log/syslog のようなテキストファイルにログを書き出します。Ubuntu 24.04でも標準でインストールされており、tail や grep で手軽に読めます。
| ログシステム | デーモン | 保存形式 | 確認コマンド | 特徴 |
|---|---|---|---|---|
| systemd-journald | systemd-journald | バイナリ（/var/log/journal/） | journalctl |
強力な絞り込み、カーネルログも統合 |
| rsyslog | rsyslogd | テキスト（/var/log/syslog等） | tail, grep |
テキストなので扱いやすい |
| カーネルログ | （カーネル） | リングバッファ | dmesg |
ハードウェア・ドライバ関連 |
ログファイルの保存場所
Ubuntu 24.04 で rsyslog をインストールすると、以下のようなログファイルが /var/log/ 以下に作成されます。実際に ubuntu:24.04 Docker公式イメージに rsyslog をインストールして確認した結果です。
主なファイルの意味：
/var/log/syslog：システム全般のログ（メイン）/var/log/auth.log：SSHログイン・sudoの認証ログ/var/log/kern.log：カーネルメッセージ/var/log/journal/：journaldのバイナリログ（永続化時）/var/log/dpkg.log：aptパッケージ操作の履歴
Ubuntu 24.04 では /var/log/journal/ ディレクトリがデフォルトで作成されており、systemd-journald のログが再起動後も残る「永続モード」が自動で有効になっています（Ubuntu 22.04 は環境によって異なります）。
journalctlでシステムログを確認する
VPSやサーバーで作業するなら、journalctlを最初に覚えてください。systemdが管理するすべてのサービスのログを一元的に扱えます。
①直近のログを表示する
— Logs begin at Fri 2026-06-13 00:00:01 JST, end at Fri 2026-06-13 18:30:45 JST. —
Jun 13 18:25:12 vps systemd[1]: Started Daily apt download activities.
Jun 13 18:28:01 vps sshd[3421]: Accepted publickey for ubuntu from 203.0.113.1 port 54321
Jun 13 18:28:01 vps systemd[1]: Started Session 12 of User ubuntu.
…
-n 50 で直近50件を表示します。デフォルトは端末に収まる件数。--no-pager を付けると less を使わず一括出力します（grepと組み合わせる時に使います）。
②特定のサービスのログだけ表示する
— Logs begin at Mon 2026-06-10 09:00:01 JST —
Jun 13 10:00:15 vps nginx[891]: 2026/06/13 10:00:15 [notice] 1#1: nginx/1.24.0
Jun 13 10:00:15 vps nginx[891]: 2026/06/13 10:00:15 [notice] 1#1: start worker processes
Jun 13 10:00:15 vps systemd[1]: Started A high performance web server and a reverse proxy server.
-u でユニット（サービス名）を指定します。nginx.service の代わりに sshd、mysql、docker など調べたいサービス名を入れてください。
③今回の起動分だけ確認する
— Boot 3a1f2e8c9b7d4a5f completed at Fri 2026-06-13 09:00:01 JST —
Jun 13 09:00:01 vps kernel: Booting Linux on physical CPU 0x0000000000 [0x412fd050]
Jun 13 09:00:01 vps kernel: Linux version 6.8.0-51-generic …
Jun 13 09:00:02 vps systemd[1]: Started systemd-journald.service …
-b（boot）で今回の起動から現在までのログだけを表示します。-b -1 で1回前の起動分、-b -2 で2回前になります。再起動後にクラッシュの原因を探すときに便利です。
④エラーログだけ絞り込む
Jun 13 09:00:08 vps kernel: [drm:amdgpu_init [amdgpu]] *ERROR* radeon: unrecognized module parameter
Jun 13 09:15:32 vps nginx[1054]: nginx: [error] open() “/var/run/nginx.pid” failed
-p err で「エラー以上」（err・crit・alert・emerg）のログだけ抽出します。今回の起動分 -b と組み合わせると、起動時のエラー原因を素早く特定できます。優先度の一覧：
emerg（0）：システム使用不可alert（1）：即対応が必要crit（2）：クリティカルな状態err（3）：エラーwarning（4）：警告notice（5）：通常だが注目すべきinfo（6）：情報debug（7）：デバッグ情報
⑤時間範囲を指定する
— Logs begin at Fri 2026-06-13 09:00:01 JST —
Jun 13 09:00:01 vps systemd[1]: Reached target Basic System.
Jun 13 09:00:05 vps sshd[841]: Server listening on 0.0.0.0 port 22.
特定の時間帯にだけ起きた障害を確認したいときに使います。--since 'today'、--since '1 hour ago' のような相対指定も可能です。
⑥リアルタイムで監視する
— Logs begin at Fri 2026-06-13 09:00:01 JST —
Jun 13 18:30:01 vps CRON[4521]: (root) CMD ( /usr/sbin/ntpdate -s ntp.ubuntu.com)
Jun 13 18:30:45 vps sshd[4522]: Invalid user admin from 198.51.100.42 port 12345
Jun 13 18:30:45 vps sshd[4522]: Connection closed by invalid user admin …
（Ctrl+C で終了）
-f（follow）は tail -f と同じ感覚で使えます。別のターミナルでサービスを再起動しながら、こちらでリアルタイムにログを見るという使い方がよくあるパターンです。
rsyslogと/var/log/syslogを使う
journalctlが入っていない・使えない環境（古いディストリビューションや特殊環境）では、/var/log/syslog を直接確認します。Ubuntu 24.04 では rsyslog 8.2312.0 が apt でインストールできます。
rsyslogのインストールと起動確認
Setting up rsyslog (8.2312.0-3ubuntu9.2) …
$ sudo systemctl status rsyslog
● rsyslog.service – System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)
Active: active (running) since Fri 2026-06-13 09:00:10 JST; 9h ago
tailコマンドで末尾を確認する
Jun 13 18:25:01 vps CRON[4210]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && …
Jun 13 18:28:01 vps systemd[1]: session-12.scope: Deactivated successfully.
Jun 13 18:30:01 vps CRON[4521]: (root) CMD ( /usr/sbin/ntpdate -s ntp.ubuntu.com)
$ tail -f /var/log/syslog
（リアルタイム表示。Ctrl+C で終了）
tail -n 30 で末尾30行を表示、-f でリアルタイム表示です。/var/log/syslog が存在しない場合は、rsyslogがインストール・起動されているか確認してください。
Ubuntu 24.04 での注意点
Ubuntu 24.04 LTS では rsyslog はデフォルトではインストールされていない場合があります（最小構成インストール時）。ls /var/log/syslog でファイルが存在しない場合は、sudo apt-get install rsyslog でインストールしてください。
grepでエラーを絞り込む
Jun 13 09:15:32 vps nginx[1054]: [error] open() “/var/run/nginx.pid” failed
Jun 13 10:03:21 vps kernel: [drm] ERROR: failed to register drm device
$ grep ‘sshd’ /var/log/auth.log | grep -v ‘Accepted’ | tail -10
Jun 13 18:30:45 vps sshd[4522]: Invalid user admin from 198.51.100.42
正直、エラー調査には grep -i 'error\|failed\|crit' をパイプでつないで流し読みするのが一番早いです。/var/log/auth.log は不正ログイン試行の確認にも使えます。SSHポートを公開していると毎日何十件も来ているはずです。
dmesgでカーネルメッセージを確認する
ハードウェア関連の問題（ディスクエラー、ネットワークドライバの問題など）は、カーネルのリングバッファに記録されます。これを確認するのが dmesg です。
Ubuntu 24.04 の dmesg は util-linux 2.39.3 に含まれており、標準でインストール済みです（実測確認済み）。
基本コマンド
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[ 0.000000] Linux version 6.8.0-51-generic (buildd@bos03-arm64-059)
[ 1.234567] EXT4-fs (sda1): mounted filesystem without journal
[ 12.345678] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
タイムスタンプ付きで表示する
2026-06-13T09:00:00,123456+0900 EXT4-fs (sda1): re-mounted. Quota mode: none.
2026-06-13T09:00:01,234567+0900 IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
$ dmesg -T | grep -i ‘error\|warn’
（タイムスタンプ付きでエラーだけ表示）
デフォルトのdmesgはシステム起動からの経過秒数で表示されます。--time-format=iso または -T を付けると人間が読みやすい日時形式になります。
journalctlでカーネルログを表示する方法
— Logs begin at Fri 2026-06-13 09:00:01 JST —
Jun 13 09:00:01 vps kernel: Linux version 6.8.0-51-generic …
Jun 13 09:00:01 vps kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.8.0-51-generic
journalctl -k（–dmesg）はdmesgと同等の内容をjournalctlで表示します。-k -p err と組み合わせると、カーネルのエラーだけ一覧できます。
Ubuntu 22.04と24.04のログ周りの変化
Ubuntu 22.04 から 24.04 にアップグレードする場合、あるいは両方を使う環境では、ログ周りの挙動差を知っておくと詰まりにくいです。
| 変更点 | Ubuntu 22.04 LTS | Ubuntu 24.04 LTS |
|---|---|---|
| systemd バージョン | 249 | 255（+6メジャー） |
| rsyslog バージョン | 8.2112.0（2021年12月） | 8.2312.0（2023年12月） |
| /var/log/journal/ 作成 | 環境依存（作成されないケースあり） | インストール時に自動作成 |
| ログ永続化デフォルト | 揮発性（/run/log/journal/）の可能性あり | 永続化（/var/log/journal/） |
| dmesg（util-linux） | 2.37.2 | 2.39.3 |
特に注目したいのはログの永続化設定の変化です。Ubuntu 22.04 では /etc/systemd/journald.conf の Storage=auto（デフォルト）の挙動が、/var/log/journal/ ディレクトリが存在するかどうかで変わっていました。ディレクトリがなければ揮発性ログ（再起動で消える）になるため、過去ログが残っていないという経験をした人もいるかもしれません。
Ubuntu 24.04 では /var/log/journal/ がインストール時に自動で作成されるため、デフォルトで再起動後もログが残ります。これは実際に ubuntu:24.04 Docker公式イメージで確認した結果です（ls -la /var/log/journal/ でディレクトリが存在することを確認）。
journald.confのStorageオプション
[Journal]
（すべてコメントアウト = デフォルト値を使用）
$ ls -la /var/log/journal/
drwxr-sr-x+ 2 root systemd-journal 4096 Jun 13 09:57 .
（ディレクトリが存在 → 永続ログ有効）
/etc/systemd/journald.conf の内容は実際に Ubuntu 24.04 Docker公式イメージで確認したもので、[Journal] セクション以下はすべてコメントアウトされています（デフォルト値が適用）。Storage=auto は /var/log/journal/ が存在すれば永続モードになります。
よくあるエラーと解決策
「No journal files were found.」と表示される
No journal files were found.
— No entries —
これはDockerコンテナやWSL2でよく出るエラーです。原因はsystemd-journaldが動いていないこと。Ubuntu公式Dockerイメージ（ubuntu:24.04）にはsystemdが含まれていますが、コンテナとして起動した場合はsystemdは動いていません。
解決策：VPSや実機にSSHして作業してください。コンテナ環境でsystemdを動かすには追加設定が必要で、通常のアプリ開発・運用では不要です。
「Permission denied」— /var/log/syslogが読めない
tail: cannot open ‘/var/log/syslog’ for reading: Permission denied
$ sudo tail /var/log/syslog
Jun 13 18:30:01 vps rsyslogd: [origin software=”rsyslogd” …]
/var/log/syslog のパーミッションは -rw-r----- root adm（グループ adm）です。一般ユーザーは直接読めません。sudo を付けるか、自分のユーザーを adm グループに追加します：
（ログアウト→ログイン後に有効）
$ tail /var/log/syslog
Jun 13 18:30:01 vps rsyslogd: [origin software=”rsyslogd” …]
journalctl の出力が大量すぎる
何万行もあって困る場合は、以下の組み合わせで絞り込んでください：
$ journalctl -u nginx.service -p err -b –no-pager
# 直近1時間のエラー
$ journalctl –since ‘1 hour ago’ -p err –no-pager
# grepと組み合わせ
$ journalctl –no-pager | grep -i ‘timeout\|connection refused’
まとめ
Ubuntuのログ確認コマンドを整理します：
- systemdサービスのログは
journalctl -u サービス名 -n 50から始める - エラーだけ見たければ
-p errを追加する - リアルタイム監視は
journalctl -f（またはtail -f /var/log/syslog） - カーネルログは
dmesg | tailまたはjournalctl -k - Ubuntu 24.04 は systemd 255、rsyslog 8.2312.0 — デフォルトで永続ログが有効
- コンテナ環境（Docker）では journalctl は使えない
ログを見ながらサーバーを運用するには、自分のVPSを持っているのが最も学びやすい環境です。月額 $5〜$6 程度から始められます。
VPS選びに迷ったら、実測ベンチマークで比較した記事も参考にしてください。
正直、journalctl を使いこなせるようになると、サーバーのトラブルシューティングが格段に早くなります。最初は journalctl -n 100 -p err だけ覚えておけば十分です。
コメント