今回のブログポストについては、正直書くべきかどうか迷いました。状況によってはこのポストをすぐに削除してしまうかもしれないということを、予めお知らせした上で書いてみることにします。
そもそも、今回のブログタイトルを見て、何を言っているのか分からないというユーザーさんは、このブログ記事を読む必要はありません。おそらくあなたは現代的で幸せなラズパイユーザーなのだと思います。
読者として想定しているのは、3月のアップデート以降デスクトップからログアウトするたびsshのリモート接続が切れてイライラしている、とか、screen or tmuxが使えなくなって殺意を覚えるとかいう、そういう古めのunixユーザーの方々です。
3月のアップデートで、デスクトップからログアウトするとすべてのユーザープロセスがkillされるよう改変されてしまった
これはバグではなく仕様変更で、リリースノートの2024-03-12の項にちゃんとした記載があります。
- Shutdown assistant now closes all user processes when logging out （ログアウト時に、シャットダウンアシスタントがすべてのユーザープロセスを閉じるようになりました。）
シャットダウンアシスタントとは、RPI OS Bookwormの左上のメインメニューからログアウトを選択すると実行されるコマンドで、実体は/usr/bin/lxde-pi-shutdown-helperです。
このコマンドはバイナリーで、ソースはこちらのpishutdown.cとなります。
c言語が得意ではない私のようなユーザーでもおぼろげに分かったのは、おそらく今回のアップデートで、新たにdefine USE_LOGINDが追加されたのだろうということです。ログアウトを選択するとlogindにdbus経由で”KillUser”が送られ、結果logindがログアウトするユーザーのプロセスをマシンガンのごとく全抹殺するという、なかなか素敵なログアウト方法に改変されたようです。
この仕様変更の良い点、悪い点
良い点はもちろん、ログアウトしたらすべてのユーザープロセスが跡形もなく消え去ってしまうことです。バックグラウンドにゴミプロセスが残ることがありませんから、とても安心だ、と考えるユーザーは多いでしょうし、それは間違いではありません。
それでも私が困っているのは、以下のような現象が起こる（あるいは起こりそう）だからです。
- リモートからsshでログインしていても強制退去させられる。
- 仮想コンソールからのログインも強制退去。
- screenやtmuxなどのセッションマネージャもkillされる。
などなど。もっと言えばデーモン化したemacsも殺されるとか、cronで起動したプロセスも間が悪いと殺されるとかもあると思うのですが、細かすぎるからやめておきます。
この仕様変更の回避が難しい理由
そもそもなんでこんな改変しやがったんだという私の怒りは置いておくとして、なんとかして回避策を考えたいところなのですが、これが割と厄介なのです。
/usr/bin/lxde-pi-shutdown-helperを適当なシェルスクリプトに入れ替えてやれ、で満足な人なら良いのですが、それは後々aptのアップグレード時に面倒が起こりそうだから避けたいのです。
話としては2016年ぐらいにsystemdが/etc/systemd/logind.confでKillUserProcesses=yesをデフォルトにする、と発表した話（あのときも相当な批判があったはず）に似ているのですが、RPI BookwormではKillUserProcessesはデフォルトでnoに設定されています。loginctl enable-lingerすればkillが回避できるとかいう話もあるので一度試してみたのですが、どうやらうまく行かないようです。
もっと頑張ればsystemdがらみでkillを阻止できる道があるのかもしれませんが、そもそもプロセスをkillされないように設定してしまうと、pishutdown.cのソースを見る限り、ログアウト自体ができなくなりそうです。そういうわけで、この方向の努力は取りやめることにしました。
一応考えた回避策
一応の回避策を考えてみました。相当原始的なやり方なのでどうかと思いますが、あまり大きくシステムを改変しなくて済むという点ではよい方法かと思い、書いておきます。
概略を述べたいのですが… ちょっとややこしいです。偽（にせ）lxde-pi-shutdown-helperと偽systemctlを用意して、これらをPATHの上位に配置して、システムに誤認させるテクニックを2重に使っています。
まず最初に偽lxde…を実行させます。そのために/etc/profile.dにファイルを置いて、システム全体のPATHをいじります。
偽lxde…から本物lxde…を呼ぶのですが、偽lxde…でPATHをいじって、本物lxde…から偽systemctlが呼ばれるように仕向けます。これにより本物lxde…はラズパイ上でlightdm（ログイン画面）が動いていないかのように錯覚します。
この場合、本物lxde…は、デスクトップが仮想コンソールなどのコマンドラインから起動されたものと判断して、KillUserを使わない通常のログアウト処理を実行します。KillUserしてしまうと、ログアウト後に戻るべきコマンドライン環境も消滅してしまってわけが分からなくなるので、それを避けるための仕様と思われます。
と説明しても、わけが分からない人がほとんどでしょうが（笑)、やることは簡単なファイルを3つ配置することだけです。以下をターミナルで実行してください。
sudo nano /etc/profile.d/top_commands.sh
# 編集内容は以下参照
sudo mkdir /etc/top_commands
sudo nano /etc/top_commands/lxde-pi-shutdown-helper
# 編集内容は以下参照
sudo chmod +x /etc/top_commands/lxde-pi-shutdown-helper
sudo mkdir /etc/top_commands/lxde-pi-shutdown-helper_hidden
sudo nano /etc/top_commands/lxde-pi-shutdown-helper_hidden/systemctl
# 編集内容は以下参照
sudo chmod +x /etc/top_commands/lxde-pi-shutdown-helper_hidden/systemctl/etc/profile.d/top_commands.sh は以下のように編集。
PATH="/etc/top_commands:$PATH"/etc/top_commands/lxde-pi-shutdown-helper は以下のように編集。
#!/bin/bash
PATH="$(readlink -f $0)_hidden:$PATH"
exec /usr/bin/lxde-pi-shutdown-helper/etc/top_commands/lxde-pi-shutdown-helper_hidden/systemctl は以下のように編集。
#!/bin/bash
echo "I am a fake systemctl!"一度ログアウトして、ログインしなおせば、profile.dで追加したPATHが有功になりそうですが、だめな場合は再起動してください。
この設定でログインして、ターミナルでwhich lxde-pi-shutdown-helperなどとすれば偽lxde…（/etc/top_commands/lxde-pi-shutdown-helper）の方のコマンドが優先されることが確認できると思います。
/usr/bin/lxde-pi-shutodown がフルパスで呼ばれてしまうとこの方法ではうまく行かないのですが、幸いにして、メニューからはlxde-pi-shutdownだけで参照されているため、偽物側が実行されます。
この方法がうまく行った場合、logout部分のメニューが”Exit to command line”に書き換わります。この状態ではKillUserを使わない、通常のログアウト処理が行わるため、安全にログアウトできます。
今回の改変ってどうなんでしょう？
このログアウト処理の改変に気づいたときの私の最初の感想は、
いやーなんかやっちゃんてんなー
というものでして、
これは非難轟々になるからすぐに戻るよなー
と高をくくって安心していたのですが、意外にそうでもない感じで、ラズパイ本部のフォーラムを検索しても特に話題に登ることはない様子なのでして、
あれ？そうなの？
まじでこのまま行っちゃうの(汗)
と焦り始めました。あげくは
ひょっとして、これが起こっているのは私の環境だけだったりするのか？
とも考えたのですが、リリースノートにはっきり書かれてる改変でもありますから、それはないだろうとも思いつつ…。なんかだんだん疑心暗鬼になってきて、ひょっとしてログアウトする時KillUser送るのが最近のはやりで、それを知らない私は古すぎのかと自問自答を始める始末。
色々ありますが、とりあえずブログにしてみようと思って書いたのが今回のポストです。私の勘違いもありそうなので、冒頭で述べたとおり、おかしな内容だと分かればポストを削除する予定であることを強調しておきます。
しかし本当にbookwormはこの方向に向かってしまうのでしょうか？ いずれにしろこういう大きな改変をマイナーアップグレードでぶっこんでくるのはやめてくれと思うのですが、最近のbookwormの改変状況を見る限り、
どうやらこの先、
また別の巨大マイナーアップグレード（？）
が待ち受けているらしい
ことが強く予想されます。
あるいは次のdebianリリースになる可能性もなくはありませんが、やつらならやっぱりマイナーアップグレードでやってしまうのではないでしょうか（笑） そういうわけで、
未だにX11を使い続けているユーザー(私のこと)は、
waylandへの移行はもう少し様子を見てからにしたほうが良いかも
とだけは言っておきます。
（追記: 混乱が起こらないように少しつづ改変を進めている感じなので、3月のアップデートのような混乱にはむしろならないと思います。パニックになるとかいう話ではないです。）
追記（ 5月1日）巨大マイナーアップグレードがついに始まる？ – labwcがリポジトリに追加される
現在のwaylandのコンポジタはwayfireですが、これを将来的に入れ替える（らしい）labwcがリポジトリに追加されました。詳しくは下の新たなポストをどうぞ。
labwcはまだテストパッケージという位置づけで、設定はまだまだ荒削りです。ただ一方で、現行のwayfireはデフォルトだと使いづらいものがあるので、X11からwaylandへの移行を考えているユーザーはlabwcの熟成を待ってからにしたほうが得策かもしれません。
コメント