みなさん、こんにちは。
先日、Xubuntu 24.04 (Noble Numbat) にデスクトップ環境「Moksha」をインストールするという記事を公開しました。
MokshaはBodhi Linuxで採用されている軽量かつ美しいデスクトップ環境ですが、これをUbuntuベースの環境で動かすのは、軽量Linuxファンとしてはたまらない「遊び」ですよね。
実は前回の記事の後、読者の方から「既存の環境でも動くのか？」というお声をいただきました。結論から申し上げますと、Xubuntu 22.04 (Jammy Jellyfish) でも全く問題なく適用可能です。インストールスクリプトを noble.install.sh ではなく jammy.install.sh に読み替えて実行するだけで、22.04環境がBodhi Linux 7.0.0相当の装いに変身します。
さて、ここからが今回の本題です。
「せっかく軽量なMoksha環境が手に入ったのだから、リモートデスクトップ（XRDP）経由でもこの快適さを味わいたい！」
そう考えたのが、今回私を襲った数時間に及ぶ「トラブルシューティングの沼」への入り口でした。
Moksha + XRDPという「禁断の組み合わせ」に挑む
私は普段、REALFORCE RC1の打鍵感とLogicool M575の滑らかな操作感をこよなく愛しているのですが、仕事の都合上、別のPCからリモートで作業環境にアクセスしたい場面が多々あります。
メインのXubuntu 22.04環境にMokshaをインストールし、いざXRDPでの接続を試みました。
通常、XRDPでデスクトップ環境を切り替えるには、/etc/xrdp/startwm.sh を編集するか、ホームディレクトリの .xsession を書き換えて exec enlightenment_start を指定するのが定石です。私はstartwm.shの最終行を編集し、Moksha（Enlightenment）が立ち上がるように仕込みました。
ところが、ログインボタンを押した先に待っていたのは、理想のデスクトップではなく、想定外の「怪奇現象」でした。
発生したトラブルの症状
- 画面の激しい点滅
→ デスクトップが描画されようとしては消え、また描画されようとしては消える無限ループ。 - xfce4-power-managerのエラー連発
→ 画面の隅で電源管理エラーの通知が鳴り止まない。 - CPUファンの爆音
→ プロセスを確認するとenlightenment+がCPUリソースを食いつぶしている。
「軽量なはずのMokshaが、なぜこんなに重いのか？」 数時間の調査の結果、XRDPとEnlightenment系（Mokshaのベース）の相性の悪さが浮き彫りになってきました。
原因の考察 – なぜ動かないのか
- セッションの残骸（ゾンビプロセス）
→ 正常起動できないため、接続を切っても、Xorgやenlightenmentのプロセスが居座り続け、次回のログイン時にリソースを奪い合っていました。 - 電源管理の干渉
→ XFCEベースの環境にMokshaを載せているため、バックグラウンドで動くxfce4-power-managerが、仮想ディスプレイ側の電源制御を奪おうとしてエラーを吐き続けていたのです。 - DPMS（画面電力管理）のエラー
→ XRDPの仮想ディスプレイは物理的なモニタではないため、Enlightenment特有の高度な画面管理機能が「モニタが見つからない」とパニックを起こしていました。
本家Bodhi Linux 7.0.0ではXRDP経由でもMokshaが動くのですが、Xubuntu上に構築した「ハイブリッド環境」では相性が最悪だったようです。「深追いは禁物」。数時間の試行錯誤の末、私は撤退を決意しました。
Xubuntu（XFCE）セッションへの撤退
「Xubuntu の Mokshaをリモートで使う」という夢は早々に諦め、XRDPの設定を標準のXubuntu（XFCE）セッションに戻すことにしました。さすがは公式サポート同士、設定を元に戻した瞬間にログインはあっさりと成功。
「やっぱり安定のXFCEだな」と胸をなでおろしたのも束の間、以前から私を悩ませていた「30分の壁」が再び立ちはだかります。
ノートPCヘッドレス運用の敵 – 自動サスペンド問題
XRDPで接続して作業をしていると、突然通信が途絶えるのです。 時計を見ると、PCに電源を入れてから、あるいはXRDPでログインしてからちょうど30分後。
そう、以前ブログでも紹介した「Xubuntu 22.04のXRDPスリープ問題」です。
通常なら、GUIの「電源管理」から設定を「何もしない」にすれば解決するはずですが、XRDP経由だとこの設定が驚くほど無視されます。OS側が「誰も物理的に操作していない＝アイドル状態」と判断してしまうのが原因です。
systemd-logind の設定が効かない理由
以前、私が対策として試したのは、システム全体の管理を司る logind.conf の編集でした。
/etc/systemd/logind.conf
------------------------
IdleAction=ignore
IdleActionSec=0
「アイドル状態でも何もしない（ignore）」という設定です。
これを反映させて systemctl restart systemd-logind を実行すれば、その場では確かにサスペンドを回避できます。
しかし、ここにも罠がありました。
この設定は「ログインしているセッション」に対しては有効ですが、PCを再起動してログイン画面（LightDMなど）で止まっている状態や、XRDPのセッションが特殊な状態で認識されている場合、システムは「誰も使っていない」と判断して sleep.target を実行してしまうのです。
つまり、一度設定して安心しても、再起動後にコマンドを叩き忘れると、30分後にはノートPCが深い眠りについてしまうのです。これでは「いつでもどこでもリモートワーク」という私のワークスタイルが成立しません。
最終解決 – sleep.target を物理的に封印する
「設定ファイルが効かないなら、サスペンドという機能そのものをOSから見えなくしてしまえばいい」
結局、行き着いた答えは、 systemdのマスク（mask）機能 です。
以下のコマンドを実行します。
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
なぜ「disable」ではなく「mask」なのか？
通常、サービスの自動起動を止めるには disable を使いますが、disable は他のサービスから呼び出された場合には動いてしまいます。
対して mask は、対象のユニットファイルを /dev/null へのシンボリックリンクに置き換えます。これにより、システム内のいかなるプロセスからもサスペンド機能を呼び出すことができなくなります。まさに「最終兵器」です。
この処置を行った結果、電源投入から30分経過しても、XRDPで長時間放置しても、ノートPCが勝手にサスペンドすることはなくなりました。
私の運用スタイル（ノートPCの蓋を閉じたままのヘッドレス運用）では、自動サスペンドが必要な場面はほぼないので、実害はありません。
もし出先などでバッテリー消費を抑えるために元に戻したい場合は、以下のコマンドで封印を解くことができます。
sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target
シンプルこそが最強のソリューション
この1日の試行錯誤を通じて学んだ教訓を整理します。
- Xubuntu + Enlightenment系（Moksha）+ XRDP ＝ 地獄
→ 見た目の美しさに惹かれますが、リモートデスクトップ用途ではおとなしく公式サポートのXFCEを使うのが正解です。Mokshaは物理マシンでのログイン専用として楽しみましょう。 systemd-logindの限界
→IdleAction設定は、グラフィカルセッションが正しく認識されていることが前提です。ヘッドレス運用や特殊なログイン環境では、期待通りに動かないケースが多々あります。sleep.targetマスクが最強
→ 「ノートPCの蓋を閉じて、常時起動サーバーとして運用する」という用途なら、中途半端な設定に頼るより、サスペンド機能を根こそぎマスクしてしまうのが一番確実で、ストレスがありません。
当初は「オシャレなMoksha環境をリモートで！」という野望から始まりましたが、最終的には「質実剛健なXubuntu + 強力なサスペンド無効化」という、非常に実用的な構成に落ち着きました。
技術の追求は時に遠回りになりますが、その過程でLinuxの深い挙動（systemdや電源管理の仕組み）を再確認できるのは、エンジニアとしての醍醐味でもありますね。
本日も最後までお読みいただきありがとうございました。
それでは、よいXubuntuライフを！
