コグノスケ

udevルールのデバッグ例

目次: Linux

最後にudevルールのデバッグ例も書いておきましょう。/dev/ttyS0の所有者をroot:dialoutにするルールを例に説明します。

$ ls -la /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Apr  5 23:12 /dev/ttyS0

udevルールは/etc/udev/rules.dではなく、/usr/lib/udev/rules.dにあります。

## /usr/lib/udev/rules.d/50-udev-default.rules

...

# ★★addイベント以外なら何もしない★★
ACTION!="add", GOTO="default_end"

SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*|hvc[0-9]*|sclp_line[0-9]*|ttysclp[0-9]*|327
0/tty[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="vc", KERNEL=="vcs*|vcsa*", GROUP="tty"
# ★★下記のルールを使って説明します★★
KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"

...

ざっくり説明すると、ACTION=addのときのみ"ttyなんとか", "ttymxcなんとか", "pppoxなんとか", ...の名を持つデバイスの所有者グループをdialoutに設定してくれ、こんな意味を持ったルールです。今回確認するポイントは、

• addイベントに反応すること
• changeイベントに反応しないこと
• 他のルールで設定されないこと

この3つを確認しようと思います。

addイベント

まずはttyS0の所有者グループを変更してrootにします。dialout以外ならなんでも良いです。

# chown root:root /dev/ttyS0

# ls -la /dev/ttyS0
crw-rw---- 1 root root 4, 64 Apr  5 23:36 /dev/ttyS0

前回紹介したシステム起動時のイベントを再現させた後に、再び所有者グループを確認します。

# systemctl restart systemd-udev-trigger

# ls -la /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Apr  5 23:46 /dev/ttyS0

所有者グループがdialoutに戻りました。

changeイベント

同様に所有者グループをrootに変更したあと、changeイベントを発生させます。

# chown root:root /dev/ttyS0

# ls -la /dev/ttyS0
crw-rw---- 1 root root 4, 64 Apr  5 23:46 /dev/ttyS0

# udevadm trigger

# ls -la /dev/ttyS0
crw-rw---- 1 root root 4, 64 Apr  5 23:48 /dev/ttyS0

所有者グループはrootのままでdialoutにはなりませんでした。想定どおりです。

他のルールで設定されないこと

あるルールを書いたが間違っていて動かなかった、だけど偶然別のルールが同じ結果をもたらしていて気づかず放置されていた……なんてことは人間誰しもやってしまう間違いです。

注目していたルールがdialoutに設定するルールだった証明をするためには、先程注目していたルールをコメントアウトします。その後addイベントを発生させ、所有者グループがdialoutに戻らないことを確認します。

## /usr/lib/udev/rules.d/50-udev-default.rules

...

# ★★addイベント以外なら何もしない★★
ACTION!="add", GOTO="default_end"

SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*|hvc[0-9]*|sclp_line[0-9]*|ttysclp[0-9]*|327
0/tty[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="vc", KERNEL=="vcs*|vcsa*", GROUP="tty"
# ★★下記ルールをコメントアウトします★★
#KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"

...

保存したら先程同様に所有者グループを変更し、addイベントを発生させたあとに所有者グループを確認します。

# chown root:root /dev/ttyS0

# ls -la /dev/ttyS0
crw-rw---- 1 root root 4, 64 Apr  5 23:54 /dev/ttyS0

# systemctl restart systemd-udev-trigger

# ls -la /dev/ttyS0
crw-rw---- 1 root root 4, 64 Apr  5 23:55 /dev/ttyS0

先程addイベントを発生させたときは所有者グループが設定されましたが、ルールのコメントアウト後は設定されなくなりました。注目していた箇所は正しかったことがわかりました。

udevルールのテスト方法

目次: Linux

何かudevの設定ルールを書いたときどうやってテストしたら良いでしょうか？udevにはわざとイベントを発生させる方法があります。調べると真っ先に下記コマンドが出てくると思います。おそらく。

# udevadm trigger

これで十分なことも多いですが、udevadm triggerだとACTION=changeのイベントしか発生せずACTION=addのイベントのデバッグができないです。例えば私のマシンでttyS0のイベントをudevadm triggerで発生させるとこんな感じで、changeイベントが発生します。

KERNEL[3314156.538635] change   /devices/pnp0/00:04/00:04:0/00:04:0.0/tty/ttyS0 (tty)
ACTION=change
DEVPATH=/devices/pnp0/00:04/00:04:0/00:04:0.0/tty/ttyS0
SUBSYSTEM=tty
SYNTH_UUID=0
DEVNAME=/dev/ttyS0
SEQNUM=8729
MAJOR=4
MINOR=64

カーネル起動後、udevが起動した時にマシンに元々装着されているデバイス全てに対してACTION=addイベントが発生するのですが、これはudevadm triggerだと再現できません。

システム起動時のイベントのテスト方法

システム起動時しか適用されないudev設定ルールをデバッグしたければ、

# systemctl restart systemd-udev-trigger

を実行すると起動時に近いudevイベントが発生します。マシンの再起動でも良いですが、いちいちマシンを再起動するのは面倒ですよね。再起動不要で試せる方法は大変便利です。例えばttyS0のイベントをsystemd-udev-triggerで発生させるとこんな感じで、addイベントが発生します。

KERNEL[3314819.021878] add      /devices/pnp0/00:04/00:04:0/00:04:0.0/tty/ttyS0 (tty)
ACTION=add
DEVPATH=/devices/pnp0/00:04/00:04:0/00:04:0.0/tty/ttyS0
SUBSYSTEM=tty
SYNTH_UUID=0
DEVNAME=/dev/ttyS0
SEQNUM=9276
MAJOR=4
MINOR=64

先程とほぼ同じですがACTION=changeではなくACTION=addになっていて、システム起動時にttyS0デバイスが追加されたイベントが再現できるわけです。

個別にじっくり

他のパターンとして、1つのデバイスだけaddやchangeイベントを発生させたい場合もあると思います。該当するデバイスファイルのsysfsを探して、ディレクトリ配下にあるueventファイルに"add"や"change"の文字列を書き込むとイベントが発生します。例えばttyS0の場合は、

# echo -n add > /sys/devices/pnp0/00\:04/00\:04\:0/00\:04\:0.0/tty/ttyS0/uevent

もしくは別の/sys/classから辿って、

# echo -n add > /sys/class/tty/ttyS0/uevent

こんな感じです。/sys/class/tty/ttyS0は/sys/devices/.../tty/ttyS0へのシンボリックリンクなので、行き着く先は一緒です。

続きはまた後日。

udevルールのマイナーな方

目次: Linux

最近udevを少しいじっていたので忘れないうちにメモします。DebianやUbuntuですとudevの設定ルールファイル（*.rules）の配置は、

• /usr/lib/udev/rules.d
• /etc/udev/rules.d

です。後者は有名なので知っていましたけど、前者を知ったのは最近でした。きっかけは/etc/udev/rules.dに一切記述がないのに、udevがパーミッションを設定しているデバイスファイルを見かけたことです。誰がどこで設定しているのか？を探して、前者の/usr/lib/udev/rules.dの存在に気づきました。

存在に気づいてからinfo udevを読んでみると、当り前ですけどちゃんとルールファイルの置き場が書いてあり、先ほどの2つだけでなく、

• /usr/lib/udev/rules.d
• /usr/local/lib/udev/rules.d
• /etc/udev/rules.d
• /run/udev/rules.d: 一時的な設定ファイルを置く場所

この4つのディレクトリだよと書いてありました。知らなんだ。

udevのイベントの確認方法

あまりudevの設定をデバッグする人は居なさそうですけど、udev設定のデバッグ時はudevが何のイベントとデバイス属性を検知したか？を知る必要があります。知る方法は簡単で、

# udevadm monitor -p

を実行するだけです。例えば私のマシンでttyS0のイベントを見ると、こんな表示になります。

KERNEL[3314156.538635] change   /devices/pnp0/00:04/00:04:0/00:04:0.0/tty/ttyS0 (tty)
ACTION=change
DEVPATH=/devices/pnp0/00:04/00:04:0/00:04:0.0/tty/ttyS0
SUBSYSTEM=tty
SYNTH_UUID=0
DEVNAME=/dev/ttyS0
SEQNUM=8729
MAJOR=4
MINOR=64

ACTION=の部分がイベントの種類です。udevを使う人に用があるイベントはaddかchangeでしょう。

続きはまた後日。