科技 · 實用指南
systemctl --user 顯示「Failed to connect to bus」？匯出變數前先證明工作階段
核對有效使用者、runtime 目錄、bus socket 與使用者管理器，再選擇符合互動登入、遠端管理或持續服務的修復。
user bus 錯誤通常源自執行身份與 login session 擁有者不一致；先保留 context，再考慮修復。
安全流程要證明四個相連 layer、分類 lifecycle、只做一個窄改動，並重跑原失敗 route。
先把訊息視為 context mismatch
`systemctl --user` 連到一個登入使用者的服務管理器；各種 bus 錯誤是 transport symptom，不證明 unit 或整個 D-Bus 損壞。
記錄原命令、UID、目標使用者、launcher、環境與完整錯誤，並標明 SSH、sudo、su、cron、CI、Ansible、container 或互動登入。
不建立物件地核對四層
核對 UID，從外部檢查 `/run/user/UID` 與 `bus` 的存在、owner、mode、type，再用 loginctl 讀 user 與 session。
不要盲目 export 猜測路徑；identity、runtime 目錄、socket 與 manager 必須一致。
區分三種執行模型
互動登入要在真實 user session 重現；一次管理要明確尋址 target manager；只有持續 user service 才評估 linger。
enable-linger 是可能跨登出及開機啟動的 lifecycle policy，不是通用修復。
改套件前先分類故障層
錯 UID 指向 sudo/su/automation；缺 runtime 或 manager 指向 login/PAM/logind；socket 缺失或 owner 錯誤指向 session lifecycle。
安裝 package、reboot、linger 或 shell 設定可能改到別層；一次只做一個有證據的改變。
透過同一 launcher 重測
修復後沿原 SSH、automation、cron 或 admin route 重跑並再核四層。
先跑 read-only manager command，再看 unit；換 shell 才成功不算完成。
明確本稽核邊界
本流程不決定 user/system unit，也不授權 linger、PAM 修改、刪 runtime file 或造 bus。
原 launcher 必須抵達正確 manager；只有明確要求時才驗證跨登出或 reboot 的 persistence。
