第3章　カーネルモジュールとランタイム管理

LPIC-2 201.3 相当

Linuxカーネルは、必要な機能を「モジュール」として動的に読み込む仕組みを持っています。デバイスドライバやファイルシステムのサポートなど、常に必要とは限らない機能をモジュール化しておくことで、カーネル本体を肥大化させずに柔軟な構成を実現しています。ここではモジュール管理に加え、ハードウェアの検知とデバイスファイルの生成を担うudevの仕組み、カーネルに関連するファイル・設定を扱います。

カーネルモジュールの管理

モジュールの取り外し（rmmodやmodprobe -r）は、そのモジュールを現在使用しているプロセスやデバイスが存在する場合には失敗します。たとえば、あるファイルシステムモジュールをまだマウント中のパーティションが使用している場合、先にアンマウントしなければモジュールを取り外せません。lsmodの出力にあるUsed by列を確認することで、そのモジュールに依存している他のモジュールやデバイスの有無を事前に把握できます。

$ lsmod | head -3
Module      Size  Used by
nf_tables  102400  1
usbcore    311296  4
$ sudo modprobe -r usbcore   # -r で取り外し（正常時は無出力）
modprobe: FATAL: Module usbcore is in use.

この行のこの値に注目： USB機器が接続されていたり、他のモジュールがusbcoreに依存していたりすると、上のようにis in useエラーになり取り外せません。lsmod | grep usbcoreの3列目（使用数）が0でない限り、先に依存元のモジュールを取り外すか機器を切り離す必要があります。

modprobe は依存モジュールも含めて自動的に解決してくれるため、通常は insmod/rmmod より modprobe を使うことが推奨されます。insmodは指定したファイル1つをそのまま読み込むだけで依存関係を解決しないため、依存する別のモジュールが未読み込みだとエラーになります。

$ modinfo usbcore | head -6
filename:       /lib/modules/6.1.0-generic/kernel/drivers/usb/core/usbcore.ko
description:    USB core
author:         Linux USB Project
license:        GPL
depends:        usb-common
retpoline:      Y

modinfo の出力にある depends 行が、そのモジュールが依存する他のモジュールを示します。modprobe はこの依存関係の情報（/lib/modules/$(uname -r)/modules.dep）を参照して自動的に必要なモジュールを解決しています。この依存関係キャッシュは depmod コマンドで再生成できます。

モジュールの永続的な読み込みとブラックリスト

modprobe でのモジュール読み込みは、再起動すると失われます。起動のたびに自動で読み込ませたい場合や、逆に特定のモジュールを絶対に読み込ませたくない場合は、設定ファイルとして永続化します。

/etc/modprobe.d/blacklist-nouveau.conf の例
blacklist nouveau
options nouveau modeset=0
# オープンソースのnouveauドライバを無効化し、代わりにプロプライエタリドライバを使う典型例

/etc/modprobe.d/custom.conf の例（alias / install の使用例）
alias eth0 e1000                    # eth0というエイリアスでe1000モジュールを紐づける
options e1000e InterruptThrottleRate=3000,3000   # e1000eドライバの特定パラメータのみ指定してロード
install pcspkr /bin/false           # pcspkr（PCスピーカー）の読み込み要求自体を/bin/falseの実行に差し替え、事実上無効化する

設定変更後は sudo update-initramfs -u（Debian系）や sudo dracut -f（RHEL系）でinitramfsを再生成しないと、ブラックリスト設定が起動時のごく初期段階で反映されないことがあります。

デバイスとモジュールの対応（modalias）

カーネルは、接続されたハードウェアごとにmodaliasという識別子文字列を生成し、この文字列とロードすべきモジュールの対応関係をカーネル自身が保持しています。modprobeが「このデバイスにはどのモジュールを読み込めばよいか」を自動判断できるのは、このmodaliasの仕組みによるものです。

$ cat /sys/class/net/eth0/device/modalias
pci:v00008086d0000100Esv00008086sd00001008bc02sc00i00
$ modprobe -c | grep e1000e                 # modprobeの設定内で該当エイリアスを検索
alias pci:v00008086d0000100Esv*sd*bc02sc00i00* e1000e

この出力のv00008086はベンダーID（Intel）、d0000100EはデバイスIDを表しており、カーネルはこれらの値をキーにしてロードすべきモジュールを検索します。あるデバイスがどのパラメータを受け付けるかを事前に調べたい場合はmodinfo -pを使います。

$ modinfo -p e1000e
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)

modinfo -pの出力の各行が、そのモジュールのoptions行で指定できるパラメータ名と説明です。/etc/modprobe.d/にoptions行を書く前に、まずこのコマンドで実際に指定可能なパラメータ名を確認するのが確実な手順です。

デバイスファイルの仕組み

Linuxでは、ハードウェアデバイスへのアクセスを「ファイル」として抽象化しており、これらは慣習的に/dev以下に置かれます。/devディレクトリの実体はdevtmpfsという特殊な仮想ファイルシステムで、カーネルがデバイスを検知するたびに、対応するデバイスファイルを自動的に生成します。

$ ls -l /dev/sda /dev/tty1
brw-rw---- 1 root disk 8, 0 Aug 20 10:00 /dev/sda
crw--w---- 1 root tty  4, 1 Aug 20 10:00 /dev/tty1

この行のこの値に注目： パーミッション文字列の先頭1文字が、そのデバイスファイルの種類を表します。bはブロックデバイス（ディスクのようにランダムアクセス可能で、一定サイズ単位で読み書きする）、cはキャラクタデバイス（端末やシリアルポートのように、データを1バイトずつの連続したストリームとして扱う）を意味します。またサイズ欄の位置に表示される「8, 0」「4, 1」は、それぞれメジャー番号・マイナー番号です。メジャー番号はドライバの種類（8はSCSI/SATAディスク、4は仮想端末）を、マイナー番号は同じドライバが扱う個々のデバイス（何番目のディスクか、何番目の端末か）を識別します。

udevの役割

udevは、カーネルがハードウェアの変化（接続・切断）を検知した際に発行するueventを受け取り、次の一連の処理をユーザー空間で行う仕組みです。

1. /dev以下にデバイスファイルを作成する
2. デバイスファイルのパーミッション（所有者・グループ・モード）を設定する
3. 用途に応じたシンボリックリンクを作成する（例：/dev/disk/by-id/...）
4. 必要に応じて、あらかじめ定義されたプログラムを起動する

現在の主要ディストリビューションでは、この処理はsystemdに統合されたsystemd-udevdデーモンが担っています。システム起動時には、すでに接続されているデバイス（起動前から挿さっているディスクなど）に対しても、あたかも今接続されたかのようにイベントを再現する「コールドプラグ」処理が行われ、これによって起動時からすべてのデバイスファイルが正しく用意された状態になります。このコールドプラグ処理は、内部的にudevadm triggerと同様の仕組みで実現されています。

udevadmの各サブコマンド

udevadmは、udev/systemd-udevdの状態を確認・操作するための統合コマンドです。

$ udevadm info --query=all --name=/dev/sda
P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
N: sda
S: disk/by-id/ata-VBOX_HARDDISK_VB1234567
S: disk/by-path/pci-0000:00:1f.2-ata-1
E: DEVNAME=/dev/sda
E: DEVTYPE=disk
E: ID_SERIAL=VBOX_HARDDISK_VB1234567
E: MAJOR=8
E: MINOR=0
E: SUBSYSTEM=block

この行のこの値に注目： S:で始まる行が、そのデバイスに対して作成されているシンボリックリンク（/dev/disk/by-id/...など）です。E:で始まる行は、そのデバイスに紐づく環境変数（プロパティ）で、後述するudevルールのENV{}キーで参照できる値そのものです。

$ udevadm info --attribute-walk --name=/dev/sda
  looking at device '/devices/.../block/sda':
    KERNEL=="sda"
    SUBSYSTEM=="block"
    ATTR{size}=="41943040"
    ATTR{queue/rotational}=="0"

  looking at parent device '/devices/.../host0/target0:0:0/0:0:0:0':
    KERNELS=="0:0:0:0"
    SUBSYSTEMS=="scsi"
    ATTRS{vendor}=="ATA     "
    ATTRS{model}=="VBOX HARDDISK   "

この行のこの値に注目： --attribute-walkは、対象デバイスだけでなく、その親デバイス（この例ではSCSIホスト）まで階層を遡って属性を表示します。「デバイス自身の属性（ATTR{}）」と「親デバイスの属性（ATTRS{}）」の違いを実際の値で確認できるため、後述するルール作成時に必ず参照するコマンドです。

$ udevadm monitor
KERNEL[123.456781] add      /devices/pci0000:00/.../block/sdb (block)
UDEV  [123.489012] add      /devices/pci0000:00/.../block/sdb (block)

この行のこの値に注目： udevadm monitorを実行した状態でデバイスを抜き差しすると、KERNELイベントとUDEVイベントの2種類が表示されます。KERNEL行は、カーネルがueventを発行した瞬間を示し、UDEV行は、systemd-udevdがそのイベントに対応するルールをすべて処理し終えた瞬間を示します。2行のタイムスタンプの差（この例では約0.03秒）が、ルール処理にかかった実際の時間です。

$ sudo udevadm trigger --attr-match=subsystem=block   # 既存のblockデバイスに対してルールを再適用（正常時は無出力）
$ sudo udevadm control --reload                        # /etc/udev/rules.d/等の変更内容をsystemd-udevdに再読み込みさせる（正常時は無出力）
$ sudo udevadm test /sys/class/block/sda                # ルール処理のドライラン（実際にはデバイスファイルを変更しない）
calling: test
version 255
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

run: '/usr/lib/systemd/systemd-hwdb' /sys/class/block/sda
ID_SERIAL=WD-WCC7K1234567
ID_FS_TYPE=ext4
ID_FS_UUID=1a2b3c4d-5e6f-7890-abcd-ef1234567890
Unload module index

この行のこの値に注目： udevadm testは実際のデバイスファイル操作を行わず、そのデバイスに対してどのルールが適用されるか（ID_SERIALやID_FS_UUIDなどの環境変数がどう設定されるか）だけを確認できます。この出力の先頭に「debugging only」という注記がある通り、本番のデバイス処理には影響しません。

udevadm triggerは、抜き差しせずに既存デバイスへルールを再適用したい場合（ルールファイルを編集した直後など）に使います。ただし新しいルールを反映させるには、先にudevadm control --reloadでルールファイル自体を再読み込みさせておく必要がある点に注意してください。udevadm testは、実際のデバイスファイル生成やスクリプト実行を行わずに、どのルールがどう評価されるかをログとして出力するデバッグ専用のコマンドです。

udevルールの書式

udevのルールは、「マッチキー（条件）」と「代入キー（アクション）」をカンマ区切りで並べた1行として記述します。

ルールファイルの配置場所と優先順位

両方のディレクトリにあるルールファイルは、ファイル名の数字プレフィックスの順（アルファベット順）で評価されます。/etc/udev/rules.d/に/lib側と全く同じファイル名のファイルを置くと、/lib側のファイルは完全に無視され、/etc側の内容だけが使われます（部分的なマージではなく、ファイル単位での完全な上書きである点に注意してください）。既存のルールに影響を与えず独自ルールだけを追加したい場合は、/lib側と重複しない新しいファイル名（例：/etc/udev/rules.d/99-mydevice.rules）を使うのが基本です。

実用的なルールの作例

ここまでの知識を組み合わせた、実務でよく使われる4つのルール例を示します。

/etc/udev/rules.d/99-usb-backup.rules（特定のUSBメモリに固定のシンボリックリンクを張る）
SUBSYSTEM=="block", ATTRS{idVendor}=="0781", ATTRS{idProduct}=="5567", ATTRS{serial}=="AA010203040506", SYMLINK+="backup-usb"

idVendor・idProduct・serialの3つを組み合わせることで、同型番の別のUSBメモリを挿しても反応せず、シリアル番号まで一致する「その1本」だけを識別できます。バックアップスクリプトから常に/dev/backup-usbという固定パスで参照できるようになります。

/etc/udev/rules.d/98-usb-serial.rules（特定のUSBシリアル変換器を固定名にする）
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyMYDEVICE"

USBシリアル変換器は抜き差しのたびに/dev/ttyUSB0・/dev/ttyUSB1のように番号が変わることがあり、複数台接続する環境では特に混乱の元になります。ベンダーID・プロダクトIDで固定名を割り当てておくと、接続順序に関わらず常に同じデバイス名で参照できます。

/etc/udev/rules.d/70-persistent-net.rules（ネットワークインターフェース名をMACアドレスで固定）
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="52:54:00:12:34:56", NAME="eth-lan0"

現在の主要ディストリビューションでは、systemdのPredictable Network Interface Namesという仕組みが既定で有効になっており、PCIバスの位置やUSBポートの位置に基づいてenp0s3のような名前を自動的に割り当てます。この仕組みは接続位置が変わらない限り再起動後も同じ名前になるという利点がありますが、NICを別のPCIスロットへ挿し替えると名前が変わってしまいます。上記のようなudevルールでMACアドレスを基準にNAMEを指定すると、物理的な挿し位置に依存しない固定名を実現できます。ただし、最新のsystemdでは同様の目的のために/etc/systemd/network/*.linkファイル（[Match] MACAddress=と[Link] Name=を指定する方式）を使うことも推奨されており、udevルールによるNAME指定は伝統的な方法として理解しておく必要があります。

/etc/udev/rules.d/95-usb-notify.rules（デバイス接続時にスクリプトを実行）
SUBSYSTEM=="usb", ACTION=="add", RUN+="/usr/local/bin/notify-usb-connect.sh"

ルールが効かないときのデバッグ手順

1. udevadm testで机上確認する： sudo udevadm test /sys/class/block/sdbを実行し、どのルールファイルが読み込まれ、どの行がマッチ・不一致になっているかをログで確認します。
2. 属性名の綴りを再確認する： udevadm info --attribute-walkの出力に実際に存在する属性名と、ルールファイルに書いた属性名が完全に一致しているか（大文字小文字・スペルミスがないか）を照合します。
3. ATTRとATTRSの取り違えを疑う： 対象デバイス自身にはない属性（親デバイスにしかない属性）をATTR{}で指定してしまっていないか確認します。親を遡って参照したい属性は必ずATTRS{}を使います。
4. ルールファイルの評価順序を確認する： 同じデバイスに対して複数のルールファイルが存在する場合、より後（ファイル名の数字が大きい方）に評価されたルールの代入内容が有効になります（:=で確定済みの値を除く）。意図した値が別のルールで上書きされていないかを確認します。

/boot 以下の構成

$ uname -r          # 現在稼働中のカーネルバージョン
6.8.0-49-generic
$ cat /proc/version # カーネルのビルド情報
Linux version 6.8.0-49-generic (buildd@lcy02-amd64-078) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #49-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 27 14:04:52 UTC 2026

この行のこの値に注目： /proc/versionにはuname -rと同じバージョン番号に加え、ビルドに使われたコンパイラのバージョンやビルド日時まで含まれます。Rocky Linux 9では5.14.0-427.13.1.el9_4.x86_64のような表記になり、ビルド情報の行もgccではなくRed Hatのコンパイラ情報になります。

複数のカーネルバージョンが /boot に共存している状態はよくあります（パッケージ更新のたびに新しいカーネルが追加され、旧バージョンが残ることが多いため）。GRUBの起動メニューでは、既定では最新のカーネルが選択されますが、新しいカーネルに問題があった場合に備えて旧カーネルも一定数残しておき、メニューから選んで起動できるようにしておくのが安全な運用です。不要になった古いカーネルは、パッケージマネージャー経由（apt autoremove や dnf remove など）で削除するのが望ましく、/boot以下のファイルを手動で消すとGRUBの設定と不整合を起こす危険があります。

sysctl — 実行時のカーネルパラメータ調整

再起動やモジュールの入れ替えなしに、実行中のカーネルの挙動を調整できるのが sysctl です。設定は /proc/sys/ 以下のファイルとしても参照・変更できます。sysctl のパラメータ名の「.」区切りは /proc/sys/ 以下のディレクトリ階層の「/」区切りにそのまま対応しており、たとえば net.ipv4.ip_forward は /proc/sys/net/ipv4/ip_forward というファイルに対応します。

$ sysctl net.ipv4.ip_forward         # 現在の値を確認
net.ipv4.ip_forward = 0
$ sudo sysctl -w net.ipv4.ip_forward=1  # 一時的に変更（再起動で元に戻る）
net.ipv4.ip_forward = 1
# /etc/sysctl.conf に書いておくと再起動後も反映される
$ cat /proc/sys/net/ipv4/ip_forward     # 同じ値をファイル経由でも確認できる
1
$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
1
# catでファイルに直接書き込んでも同じ効果（sysctl -wの内部動作もこれに近い）

この行のこの値に注目： sysctl -wは変更後の値をそのままパラメータ名 = 値の形式で表示します。teeコマンドも指定した値を標準出力にそのまま返すため、echo 1 | sudo tee /proc/sys/...の実行結果に1とだけ表示されるのは正常な動作です。

よく調整されるカーネルパラメータ

読み込みの優先順位にも注意が必要です。sysctlの設定ファイルは /etc/sysctl.d/、/run/sysctl.d/、/usr/lib/sysctl.d/ など複数のディレクトリに分散して置くことができ、ファイル名のアルファベット順に読み込まれます。同じパラメータが複数のファイルで指定されている場合は、後から読み込まれたファイルの値で上書きされるため、ファイル名の先頭に数字を付けて読み込み順序を明示しておくと意図しない上書きを防げます。

uname — カーネル情報の確認

現在稼働しているカーネルのバージョンやアーキテクチャを確認したいときはunameを使います。トラブル報告や、特定のカーネルバージョンでのみ発生する不具合の調査を行う際、最初に確認する情報の一つです。

$ uname -r     # カーネルのリリースバージョンのみ表示
5.15.0-91-generic
$ uname -a     # カーネル名・ホスト名・バージョン・アーキテクチャなどをまとめて表示
Linux web01 6.8.0-49-generic #49-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 27 14:04:52 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

この行のこの値に注目： uname -aの出力は左から「カーネル名・ホスト名・カーネルリリース・ビルド日時・アーキテクチャ×3・OS名」の順で並びます。サポート対応や障害報告でシステム情報を伝える際は、この1行をそのまま貼り付けるだけで主要な情報が揃います。

カーネルを更新するパッケージ（linux-image-*など）をインストールしても、再起動するまではuname -rの表示は変わりません。「アップデートを適用したはずなのに古いバージョンのまま」と感じたら、まず再起動が済んでいるかを確認しましょう。

ライブパッチという再起動不要の選択肢

カーネルの再起動は、稼働中のサービスをすべて停止させる必要があるため、24時間稼働が求められるサーバーでは大きな制約になります。この課題に対応するため、一部のディストリビューションではライブパッチ（kpatch、kgraft、Ubuntuのcanonical livepatchなど）という仕組みが提供されています。これはセキュリティ修正などの限定的なパッチを、システムを再起動せずに稼働中のカーネルへ動的に適用する技術です。すべての種類の更新に対応できるわけではありませんが、重大な脆弱性が見つかった際の緊急対応や、計画停止の頻度を減らしたい場面で活用されています。