コグノスケ

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でしょう。

続きはまた後日。

xrdpに接続しても画面がなかなか表示されない

目次: Linux

ネットワークが不安定な環境でLinux PCのxrdpサーバーに接続していると、下記のようなログが出てネットワーク要因で切断されることがあります。

[INFO][com.freerdp.client.common] - [client_auto_reconnect_ex]: Network disconnect!

切断後に再接続できますが、ときおり画面が真っ黒なまま表示されなくなる、もしくは表示に長い時間が掛かることがあります。xrdpのコードを追ったわけではないので断定はできませんが、

• xrdp接続を受け付けるxrdpサービスの下にxrdpプロセスが複数溜まっている
• xrdpプロセスの接続相手がネットワーク的に不通

だとこの症状が発生するようです。このとき接続先サーバー（Ubuntu 24.04 LTSを使用）のプロセス一覧を見るとxrdpのセッションを維持していると思われるプロセスが残っています。

  |-xrdp,1812,xrdp   ★★サービス
      `-xrdp,1187497 ★★配下にxrdpが残っている
  `-xrdp-sesman,1756
      `-xrdp-sesman,2791
          |-Xorg,2809,katsuhiro :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log

この状態にハマってfreerdpなどクライアント側の画面が出ない状態になったら、接続先のサーバーマシンのプロセス一覧を調べ、xrdpサービス配下に溜まっているxrdpサーバープロセスをkillコマンドで強制的に終了させると画面がすぐ表示されるはずです。

  |-xrdp,1812,xrdp   ★★サービスは終了させてはだめ
      `-xrdp,1187497 ★★配下にxrdpが残っていたら終了させる
  `-xrdp-sesman,1756
      `-xrdp-sesman,2791
          |-Xorg,2809,katsuhiro :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log

注意点はなんだろな？強いて言えば、xrdpサービスやxrdp-sesmanサービスを終了させないようにするくらいでしょうか。間違ってxrdpサービスを止めてしまうと、サーバー側のリモートデスクトップ環境で起動していたアプリケーションも終了してしまい、場合によっては変な状態で残って動かなくなったりします。

首都高バトルSteam版、フルチューン後の姿 - その2

目次: ゲーム

首都高バトル（Steam版）高ランクの車をひたすらフルチューンするやつの続きです。前回と合わせて6車種ほどフルチューンしましたが、私程度の腕だと車を乗り変えても違いがわかりません。逆に考えれば、速さを気にせず好きな車を選べるので嬉しい要素かもしれない。

そういえば、このゲームのランエボは動きが変？でフルブレーキングすると斜めにズレやすいです。車体を完全にまっすぐにしないと勝手に斜めに突っ込んでいきます。なんで？？

TOYOTA MARK X(GRX133)フルチューン

MITSUBISHI LANCER EVOLUTION(CZ4A)フルチューン

MAZDA RX-7(FD3S)フルチューン

検索用にフルチューン後の主要パラメータを書いておきます。ちなみにスピード指標はギア比を最高速重視にすると高い数値になるので、参考程度です。

あとはスープラ、インプレッサのどれか、最初期にお世話になったスイスポをフルチューンする予定です。その後も遊ぶかどうかは気分次第です。だいぶ飽きてきました。

アーリーアクセスの先に期待する要素

アーリーアクセス版を脱する際に追加してほしい要素は2つです。1つ目は新しい車の追加。今は10〜20年前の車がほとんどで中古車市を見ている気分です。2つ目はコース追加。首都高を名乗るならC2や外環もほしくないですか？コース追加はダウンロードコンテンツでも買います。あと個人的には昼や夕方の景色が欲しいですが、ゲームのコンセプトに反するかなあ。

一方でライバルチームや絶対勝てない系ボスのような、安易な追加要素をしてお終いならもう二度と遊ばないでしょう。