コグノスケ

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サービスを止めてしまうと、サーバー側のリモートデスクトップ環境で起動していたアプリケーションも終了してしまい、場合によっては変な状態で残って動かなくなったりします。

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

続きはまた後日。

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ルールのデバッグ例も書いておきましょう。/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イベントを発生させたときは所有者グループが設定されましたが、ルールのコメントアウト後は設定されなくなりました。注目していた箇所は正しかったことがわかりました。

Google Pixel 8a

4年前に購入したGoogle Pixel 4aのバッテリーが劣化してきたらしく、頻繁に使うと1日で電池が尽きてしまいます。あとマイナカードアプリにも見捨てられたのか、アプリが動かなくなっていました。悲しいね。

買い替え時と判断してGoogle Pixel 8aを買いました。Googleストアで73,000円です。Pixel 4aは45,000円だったので、ずいぶん高くなったなあ。新しい方が好きな人は、新発売のPixel 9aでも良いかもしれません。値段は大差ないです。私はあまりこだわりがないので、スマホは動けばOKです。

指紋認証の性能が劣化した

Pixel 4aでは筐体裏に配置された指紋認証デバイスがとても便利でした、速いし認識率も高かったです。Pixel 8aはディスプレイ側に指紋認証装置が移動して使いづらいうえに、認識率がイマイチになりました。指紋認証を3回くらい失敗すると、その後に成功しても結局PINの入力が必要になりロック解除が面倒です。個人的にはUX体感がかなり劣化しました。うーん、イマイチ！

ユーザー側でできる工夫としては、指紋の登録をするときに指を平らに押し当てるのではなく、ロック解除を想定した角度で指紋を登録すると多少マシになるようです。画面表示では、指の右端や左端を登録しろと言ってきますが、ロック解除時に絶対触らない角度で無理に登録すると認識率が下がる気がします。指紋認証に関してはPixel 4aの方が断然良かったですね……。

Androidの買い替えは面倒くさい

アプリ情報は勝手に移行してくれるのかと思っていましたが、全くそんなことはありませんでした。アプリはインストールされるだけでログイン情報などは全てすっ飛びました。最近はいろんな店で専用アプリをインストールさせられるため、あらゆるアプリでログインし直す必要があってクッソ面倒くさいです。

面倒すぎてせっかく買ったPixel 8aを5日くらい放置してました。途中でログインし直しが嫌になってログインが必要なアプリはいくつか葬りました。もうやりたくないわこれ。