LinuxLinux [リナックス / ライナックス]オープンソースのOSカーネルサーバーを運用していると、「サーバー起動時にハードウェアが正しく認識されているか確認したい」「プロセスが突然終了したが、メモリ不足(OOM Killer)によるものか調査したい」といった状況に遭遇することがあります。
Linuxのカーネルが出力するメッセージを確認する際に利用されるのが dmesg コマンドです。
この記事では、dmesg コマンドの基本的な使い方から、実務で頻繁に利用される日時表示オプション(-T)、ログレベルによるフィルタリング、OOM Killerの調査手順、実行権限エラーの対処法までを実機検証を交えて分かりやすく解説します。
この記事でわかること
dmesgコマンドの役割とカーネルリングバッファの仕組み- 起動からの秒数ではなく、人間が読める通常の日時形式でログを表示する方法
- エラーや警告のみを絞り込んで効率的にトラブルシュートする方法
- メモリ不足によるOOM Killerの発動履歴を調査する具体的な手順
Operation not permittedエラーが発生する原因と適切な対処法
確認した環境
本記事で解説する手順や出力結果は、以下の環境で動作を確認しています。
- OSOS [オーエス]Operating System。基本ソフトウェア: DebianDebian [デビアン]コミュニティ主導で開発される安定性の高いLinuxディストリビューション GNU/Linux 11 (bullseye) / UbuntuUbuntu [ウブントゥ]人気のLinuxディストリビューション 22.04 LTS
- ソフトウェア:
dmesgfrom util-linux 2.36.1
dmesgコマンドとは?カーネルログを確認する仕組み
dmesg(display message)は、Linuxカーネルが出力するログメッセージ(カーネルリングバッファ)を表示するためのコマンドです。
システムが起動してから現在に至るまでに、カーネルが検知したハードウェアの認識状態、ドライバの読み込み状況、ファイルシステムのエラー、メモリ管理イベント(OOM Killerなど)が記録されています。
カーネルリングバッファの特徴
カーネルメッセージはメモリ上の「リングバッファ(循環バッファ)」と呼ばれる固定サイズの領域に保存されます。
リングバッファには以下の特徴があります。
- ディスクへの書き込み不要: システム起動直後など、ディスク(ファイルシステム)がマウントされる前の極めて早い段階からログを記録できます。
- 古いログの自動上書き: バッファの上限サイズに達すると、最も古いメッセージから順に新しいメッセージで上書きされます。
- 高速な動作: メモリ上に展開されているため、ディスクI/Oの負荷をかけずに直近のカーネル状態を取得できます。
システム全体のログを長期間保存・管理するツールとして journalctl や /var/log/syslog(/var/log/messages)が存在しますが、カーネル自体の低レイヤーな挙動やハードウェア障害、即時のトラブル調査には dmesg が適しています。
dmesgコマンドの基本的な使い方
dmesg コマンドの基本構文は非常にシンプルです。
dmesg [オプション]※最近のLinuxディストリビューションではセキュリティ制限(kernel.dmesg_restrict)により、一般ユーザーでの実行が制限されている場合があります。その場合は sudo dmesg のように管理者権限で実行します。
オプションなしで実行した場合の出力
オプションを指定せずに実行すると、バッファ内に保持されているすべてのカーネルメッセージが出力されます。
sudo dmesg | head -n 5実機での実行例:
[ 0.000000] Linux version 5.10.0-29-cloud-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.216-1 (2024-05-03)[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-29-cloud-amd64 root=UUID=3f523b33-8af7-401c-a7f5-3b5e6a74cde7 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0[ 0.000000] BIOS-provided physical RAM map:[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] reserved[ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x0000000000054fff] usable行頭にある [ 0.000000] や [ 0.336888] などの数値は、システムが起動してからの経過秒数(秒.マイクロ秒) を表しています。
このままだと「具体的に何月何日の何時何分に発生したイベントなのか」が直感的に分からないため、実務では次に紹介する -T オプションを併用するのが一般的です。
実務で役立つdmesgコマンドの主要オプション
dmesg にはログ調査を効率化するための便利なオプションが多数用意されています。実務でよく利用される代表的なオプションを順に解説します。
1. 人間が読める日時形式で表示する(-T オプション)
-T(または --ctime)オプションを付与すると、起動からの経過秒数を通常の日時フォーマット(曜日・月・日・時刻・年)に変換して表示します。
sudo dmesg -T | head -n 5実機での実行例:
[Sun May 26 23:29:15 2024] Linux version 5.10.0-29-cloud-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.216-1 (2024-05-03)[Sun May 26 23:29:15 2024] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-29-cloud-amd64 root=UUID=3f523b33-8af7-401c-a7f5-3b5e6a74cde7 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0[Sun May 26 23:29:15 2024] BIOS-provided physical RAM map:[Sun May 26 23:29:15 2024] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] reserved[Sun May 26 23:29:15 2024] BIOS-e820: [mem 0x0000000000001000-0x0000000000054fff] usable「障害が発生した時刻」や「他サーバーとのログ突き合わせ」を行う際には、この -T オプションを付けて実行するのが基本です。
2. ログレベルでエラーや警告を絞り込む(-l オプション)
カーネルメッセージには syslog と同様にログレベル(重大度)が設定されています。システムに異常が発生した際、膨大なログの中からエラーや警告のみを抽出するには -l(または --level)オプションを使用します。
指定可能な主なログレベルは以下の通りです。
| ログレベル | 重大度 | 内容 |
|---|---|---|
emerg | 0 | システムが利用不可能な緊急事態 |
alert | 1 | 即座に対処が必要な問題 |
crit | 2 | 致命的なエラー |
err | 3 | 通常のエラー |
warn | 4 | 警告メッセージ |
notice | 5 | 通常だが注意すべきメッセージ |
info | 6 | 情報メッセージ |
debug | 7 | デバッグレベルの情報 |
エラー(err)と警告(warn)の両方をカンマ区切りで指定して日時付きで確認するコマンド例は以下の通りです。
sudo dmesg -T -l err,warn | head -n 5実機での実行例:
[Sun May 26 23:29:15 2024] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.[Sun May 26 23:29:15 2024] TAA CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html for more details.[Sun May 26 23:29:15 2024] MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details.[Sun May 26 23:29:15 2024] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.[Sun May 26 23:29:16 2024] i8042: Warning: Keylock activeこのように指定することで、通常の起動ログに埋もれることなく、システムが抱える警告やハードウェア関連のエラーを迅速に洗い出すことができます。
3. リアルタイムにカーネルログを監視する(-w オプション)
ハードウェアの抜き差しやネットワーク機器の接続、特定の負荷テストを実施しながらリアルタイムにカーネルログの出力を追跡したい場合は、-w(または --follow)オプションを使用します。
# リアルタイムでログを追跡監視(終了は Ctrl + C)sudo dmesg -wこれは tail コマンドの -f オプションと同様の挙動をし、新しいカーネルメッセージが生成されるたびに画面へ随時追加出力されます。
4. 人間が見やすいフォーマットで表示する(-H オプション)
-H(または --human)オプションを使用すると、日時の読みやすい表示、カラー表示、および自動的なページャー(less 相当)によるスクロール表示が有効になります。
sudo dmesg -Hターミナル上でログをじっくりスクロールしながら確認したい場合に重宝します(終了時は q キーを押します)。
実務トラブルシューティングでの実践活用例
dmesg コマンドが実際のサーバー運用現場でどのように活用されているか、代表的な3つのユースケースを紹介します。
ケース1: OOM Killer(Out of Memory)の発動履歴を調査する
「JavaJava [ジャバ]オブジェクト指向プログラミング言語アプリケーションやデータベースプロセスが前触れなく突然死した」という場合、Linuxカーネルの OOM Killer が発動してプロセスを強制終了した可能性が考えられます。
サーバー全体のメモリ使用状況の確認には free コマンドがよく用いられますが、実際に OOM Killer が発動したかどうかの履歴はカーネルが出力するため、dmesg で確認するのが最も迅速です。
# 日時表示付きで OOM や killed process の文字列を検索sudo dmesg -T | grep -i -E "oom|killed process"もし OOM Killer が発動していた場合、以下のようなログが出力されます。
[Tue Nov 10 14:23:45 2026] Out of memory: Killed process 12345 (java) total-vm:4194304kB, anon-rss:2097152kB, file-rss:0kB, shmem-rss:0kBプロセスIDやプロセス名、消費していたメモリサイズ(total-vm や anon-rss)が記録されているため、プロセス終了の原因がメモリ枯渇であったことを客観的に裏付けることができます。
ケース2: ストレージのI/Oエラーやファイルシステム異常の検知
ディスクの劣化やI/O遅延が発生した際、カーネルはデバイス名(sda や nvme0n1 など)とともにエラーをログに出力します。
# ディスク関連のエラーメッセージを検索sudo dmesg -T -l err,crit,alert | grep -E "sd[a-z]|nvme|I/O error|EXT4-fs"ファイルシステムが読み込み専用(Read-Only)に切り替わってしまった場合や、ブロックデバイスへの読み書きタイムアウトが発生した場合も、dmesg を確認することで原因部位を特定できます。
ケース3: 外部デバイスや仮想ネットワークの接続確認
USBストレージの接続時や、DockerDocker [ドッカー]コンテナ型仮想化プラットフォーム・KubernetesKubernetes [クーバネティス / クベルネテス]コンテナオーケストレーションシステムなどによる仮想ネットワークインターフェース(veth 等)の作成・リンクアップ状況を確認する際にも活用できます。
# 最近接続されたUSB機器やネットワークリンクの確認sudo dmesg -T | grep -E "usb|eth[0-9]|enp|veth" | tail -n 10よくあるエラーと対処法(Operation not permitted)
dmesg コマンドを実行した際、以下のようなエラーメッセージが表示されて出力が得られないことがあります。
dmesg: read kernel buffer failed: Operation not permitted原因: kernel.dmesg_restrict の制限
近年の Linux ディストリビューション(Ubuntu 20.04以降、Debian、RHEL系など)では、カーネルログに含まれる機密情報(メモリのアドレス空間情報など)を悪用したセキュリティ攻撃を防ぐため、一般ユーザーによるカーネルバッファの読み取りが制限されています。
現在の設定値は以下のコマンドで確認できます。
/sbin/sysctl kernel.dmesg_restrict出力結果:
kernel.dmesg_restrict = 1値の意味は以下の通りです。
0: すべてのユーザーがdmesgを実行可能1:CAP_SYSLOG権限(または管理者root権限)を持つユーザーのみ実行可能
対処法
対処法1: sudo を付けて実行する(推奨)
セキュリティ上、最も安全で標準的な対処法は sudo を付与して実行することです。
sudo dmesg -T対処法2: 一般ユーザーの閲覧を恒久的に許可する場合
開発環境や閉じた検証環境において、一般ユーザーでも常時 dmesg を実行できるようにしたい場合は、設定ファイルを変更します。
/etc/sysctl.d/99-dmesg.conf などの設定ファイルを作成し、以下の行を記述します。
kernel.dmesg_restrict = 0設定を即座に反映させるには、以下のコマンドを実行します。
sudo sysctl -p /etc/sysctl.d/99-dmesg.conf本番環境ではセキュリティポリシーを確認した上で慎重に設定してください。
まとめ
Linuxの dmesg コマンドは、カーネルリングバッファに記録されたシステム起動情報やハードウェア状態、エラーログを確認するための基本ツールです。
要点のまとめ
- 基本:
dmesgはメモリ上のリングバッファからカーネルログを取得する - 時間表示: 人間が読める日時に変換するには
-T(--ctime)オプションを付与する - 絞り込み: エラーや警告の調査には
-l err,warnオプションを活用する - リアルタイム監視: ログを追跡する場合は
-w(--follow)オプションを使用する - OOM Killer調査: プロセス強制終了の原因究明には
dmesg -T | grep -i oomが有効 - 権限エラー:
Operation not permittedが出た場合はsudoを付与して実行する
サーバー障害の初動調査やリソース不足の特定において、dmesg は原因を迅速に特定するための強力な手がかりとなります。オプションを組み合わせて実務で役立ててください。
以上で本記事の解説を終わります。
よいITライフを!
人気記事
- 1
- 2
- 3
- 4
- 5
Rocky Linux対応。実際にWebサーバーを公開するまでのプロセスを体験できる、最も確実で実践的なガイドブックです。