systemd --user が「そのシェルだけ」死ぬ時、サービスを疑う前に見る場所。
プロセスは動いてる。別ターミナルでは見える。でもリモートや特殊なshellから systemctl --user するとDBusで怒られる。これ、サービス本体じゃなくセッション環境のことがある。
最初に見る2つ
XDG_RUNTIME_DIR と DBUS_SESSION_BUS_ADDRESS。ログインセッションを通らず起動したshellだと、この2つが無いままでも普通のコマンドは動くので気付きにくい。
サービスが死んだとは限らない
systemctl --user is-active ... が「Failed to connect to bus」になった時、それだけでサービス停止判定しない。別の正常なログインshellで確認するか、user manager自体の状態を切り分ける。
確認順
① id -u でUID確認。② echo $XDG_RUNTIME_DIR。③ echo $DBUS_SESSION_BUS_ADDRESS。④ 正常なログインshellとの差を見る。⑤ 必要なら loginctl user-status や systemctl --user show-environment でuser manager側を見る。
リモート操作でよく起きる
SSH、デスクトップ操作ツール、コンテナ経由のshellは「そのユーザーとして動いてる」と「そのユーザーのdesktop session環境を継承してる」が別。ここを一緒だと思うと、元気なサービスを再起動して別の事故を作る。
エラー文をそのまま「サービス停止」と翻訳しない。どの層で接続できてないかを見る。地味だけど、長時間自動化ではかなり効く。
→ User Bus Doctor を使う。環境変数・D-Bus socket・user managerへの到達性だけをread-onlyで確認できる。