dmesg 入門 - カーネルログでハードウェア・起動の問題を読む

dmesg 入門 - カーネルログでハードウェア・起動の問題を読む
読了時間: 約9分 難易度: 中級

この記事で解決できること

  • dmesg で カーネルリングバッファ を読み、起動・ハードウェアの異常を特定できる
  • タイムスタンプ・ログレベル・追従表示など 実務で効くオプション を使い分けられる
  • 「ディスク I/O エラー」「OOM Killer」「デバイス未認識」などの 定番障害を切り分け できる
  • dmesg と journalctl -k の 使い分け が分かる

結論（実務の型）

  • まず sudo dmesg -H で全体を眺める（色付き + ページャ）
  • 障害の時刻を掴むなら dmesg -T、新着を追うなら dmesg -w
  • レベルで絞るなら dmesg -l err,warn、キーワードは grep -i
  • 再起動後も残したいログは journalctl -k（リングバッファは揮発する）

前提（対象環境）

  • OS：Ubuntu / Debian / RHEL 系などの systemd Linux
  • util-linux の dmesg（ほぼ全ディストリ標準）
  • 多くの環境で読み取りに sudo が必要（後述）

dmesg とは何か？

結論: dmesg はカーネルが出力したメッセージを保持する「リングバッファ」を表示するコマンド。起動ログやハードウェア検出の記録を読むための入口。

dmesg（diagnostic message）は、Linux カーネルが生成したメッセージ群を表示する。これらは カーネルリングバッファ と呼ばれる固定サイズのメモリ領域に蓄積される。

カーネルはブート時のハードウェア検出、ドライバの読み込み、デバイスの抜き差し、ファイルシステムのマウント、I/O エラーなどをここに記録する。アプリケーションのログではなく、OS の最下層で起きたこと を観測できるのが dmesg の役割。

$ sudo dmesg
[    0.000000] Linux version 6.8.0-106-generic ...
[    0.004000] Memory: 16310632K/16777216K available ...
[    2.314551] usb 1-2: new high-speed USB device number 3 ...
[    2.461230] ata1.00: configured for UDMA/133

リングバッファは 固定サイズ のため、古いメッセージは新しいメッセージで上書きされる。さらに再起動すると消える。永続的に残したいログは後述の journalctl -k を使う。

なぜ root 権限が必要なのか？

結論: 多くのディストリは kernel.dmesg_restrict=1 で非特権ユーザーの読み取りを禁じている。sudo dmesg で読むのが基本。

近年の Ubuntu などでは、セキュリティ設定 kernel.dmesg_restrict が 1 になっており、一般ユーザーは dmesg を読めない。カーネルログにはアドレスなど攻撃の手がかりになる情報が含まれ得るためだ。

# 現在の設定を確認
$ sysctl kernel.dmesg_restrict
kernel.dmesg_restrict = 1

1 なら sudo が必要。0 なら一般ユーザーでも読める。

$ sudo dmesg

恒久的に一般ユーザーへ開放することも可能だが、セキュリティ上の理由で制限されている設定なので、基本は sudo を付ける 方針が無難。

ログはどう読むのか？

結論: 素の dmesg は読みにくい。-H（色付き + ページャ）、-T（人間可読時刻）、-x（レベル表示）の3つを押さえれば一気に読みやすくなる。

-H：色付き + ページャで全体を眺める

$ sudo dmesg -H

-H（--human）は色付け・相対時刻の整形・ページャ（less）起動をまとめて有効化する。まず全体を俯瞰したいときの定番。

-T：いつ起きたのかを実時刻で見る

デフォルトの [ 2.314551] は 起動からの経過秒数。実際の日時を知りたいときは -T を使う。

$ sudo dmesg -T
[Thu Jun  5 09:12:47 2026] usb 1-2: new high-speed USB device number 3 ...

-T のタイムスタンプは稼働時間から逆算した近似値。サスペンド／レジュームを挟むとずれることがある。正確な時刻が重要なら journalctl -k の方が信頼できる。

-x：どのレベル・どの分類かを表示する

$ sudo dmesg -x
kern  :err   : [    3.821] EXT4-fs error (device sda1): ...
kern  :info  : [    2.314] usb 1-2: new high-speed USB device ...

各行の facility（分類）と level（重大度）が頭に付くため、深刻な行を目視で拾いやすくなる。

どうやってリアルタイムに監視するのか？

結論: dmesg -w で新着メッセージを追従表示できる。USB を挿す・デバイスを操作するなど、操作とログを対応付けたいときに有効。

$ sudo dmesg -w

-w（--follow）は tail -f のようにバッファを開いたまま待機し、新しいカーネルメッセージが出るたびに表示する。例えば USB メモリを挿した瞬間に何が認識されるかをその場で観察できる。Ctrl + C で終了。

既存ログを出さず新着だけ見たいなら dmesg -W（--follow-new）。挿抜テストの切り分けで便利。

ログレベルでどう絞り込むのか？

結論: dmesg -l err,warn で重大度を絞れる。レベルは emerg / alert / crit / err / warn / notice / info / debug の8段階。

大量の info 行に埋もれた異常を探すなら、レベルでの絞り込みが効く。

# エラーと警告だけ表示
$ sudo dmesg -l err,warn
[    3.821] EXT4-fs error (device sda1): ext4_find_entry: ...
[   12.044] ata1.00: failed command: READ FPDMA QUEUED

カーネルメッセージだけに限定するなら -k（--kernel）、特定の分類で絞るなら -f kern のように --facility を使う。

キーワード検索は grep と組み合わせるのが手早い。-i で大文字小文字を無視する。

$ sudo dmesg | grep -i 'error\|fail\|warn'

ハードウェア・起動の問題をどう探すのか？

結論: 症状ごとに探すキーワードがある。ディスクなら ata／I/O error、メモリ枯渇なら Out of memory、デバイス未認識なら usb／firmware を起点にする。

ディスク・ストレージの異常

$ sudo dmesg | grep -iE 'ata[0-9]|i/o error|ext4-fs|sd[a-z]'

I/O error、ata1.00: failed command、EXT4-fs error などが出ていれば、ディスクまたは接続の劣化を疑う。lsblk / blkid でデバイス構成と突き合わせる。

メモリ枯渇（OOM Killer）

プロセスが突然死した原因が掴めないとき、OOM Killer が候補になる。

$ sudo dmesg | grep -i 'out of memory\|oom-killer\|killed process'
[ 1843.221] Out of memory: Killed process 2217 (java) total-vm:4513980kB ...

カーネルがメモリ不足で特定プロセスを強制終了した記録。どのプロセスが落とされたかが分かる。

デバイス・ドライバの未認識

$ sudo dmesg | grep -iE 'usb|firmware|failed to load|no such device'

firmware: failed to load や failed to load は、ドライバ・ファームウェアの不足を示すことが多い。

リングバッファは揮発する。問題発生から時間が経っていると該当ログが既に上書きされていることがある。その場合は journalctl -k --boot=-1 で前回起動分を確認する。

dmesg と journalctl はどう違うのか？

結論: dmesg は揮発するリングバッファの即時表示、journalctl -k は永続化されたカーネルログ。過去の起動まで遡るなら journalctl が必須。

観点 dmesg journalctl -k
データ源 カーネルリングバッファ systemd-journald（永続可）
再起動後に残るか 残らない（揮発） 永続化設定なら残る
過去の起動を見る 不可 --boot=-1 で可能
タイムスタンプ精度 -T は近似 実時刻で正確
即時性・手軽さ 高い やや高機能 
# 今回の起動のカーネルログ
$ journalctl -k

# 前回起動のカーネルログ
$ journalctl -k --boot=-1

即座に今の状態を見るなら dmesg、後から障害を追跡・遡及するなら journalctl -k。両者は競合せず役割分担する。詳しくは journalctl の使い方 を参照。

よく使うコマンドまとめ

結論: sudo dmesg -H で眺め、-T／-w／-l で絞り、残すなら journalctl -k。この型で大半の調査は回る。

コピペ用：dmesg 調査テンプレ

# まず全体を色付き + ページャで
sudo dmesg -H

# 実時刻で確認
sudo dmesg -T

# エラー・警告だけ
sudo dmesg -l err,warn

# 新着を追従（USB挿抜テスト等）
sudo dmesg -w

# 症状別キーワード検索
sudo dmesg | grep -iE 'i/o error|oom|firmware'

# 永続ログ / 前回起動
journalctl -k --boot=-1

次に読む