這篇講的是一套判讀紀律，不是某個特定工具。後面幾篇（遠端連線與終端機問題、機器連不到或起不來、程序、服務與狀態怎麼判）是這套紀律在各種具體情境的應用。

表象會騙人：一個判斷被畫面帶偏兩次的實例

一個具體案例最能說明為什麼不能靠肉眼。在一次桌面 shell（畫桌面 UI 的圖形程式，不是 bash/zsh 那種命令列 shell）的除錯裡，畫面中央出現一個「輸入密碼」的覆蓋層，配著時鐘、天氣、通知的整片儀表板。第一眼的判斷很自然：螢幕被鎖住了。

接著幾個看似合理的檢查反而把判斷帶得更偏：loginctl 查不到這個 session 的 LockedHint、pgrep 找不到任何獨立的鎖屏程式、那個 shell 的 CLI 也沒有 lock 指令。三個訊號湊起來，得出一個「更正」的結論：這不是真的鎖，只是一個長得像鎖屏的儀表板面板。

這個「更正」是錯的。真正定案是靠讀那個 shell 自己寫的 log：log 裡明明白白有鎖屏模組被載入、有 idle 計時器在數秒數、時間到就觸發鎖定。它是一個真的螢幕鎖，走的是 Wayland 的 session-lock 協議。

為什麼前面三個檢查會誤導？因為它們讀的是錯的權威來源。loginctl 的 LockedHint 是 logind（systemd 的登入管理）那一層的鎖定狀態，而這個鎖走的是 Wayland 合成器（compositor，負責把視窗合成到螢幕、管輸入輸出的核心程式）那一層的協議，兩者是獨立機制——查 logind 對合成器層的鎖天生查不到，不是「沒鎖」，是查錯地方。pgrep 找不到獨立程式，是因為鎖屏畫面由 shell 主程式在自己的行程內畫，本來就沒有另一個可執行檔可抓。真正記錄「有沒有鎖、為什麼鎖」的權威來源，是那個 shell 的 log；讀到它，一次就定案。

肉眼加上讀錯層的檢查，猜錯了兩次；讀對權威來源，一次就對。教訓不是「那些工具沒用」，是要先確認你讀的是不是這件事的權威狀態。

每種問題都有它的權威狀態來源

除錯的第一步，是為眼前的現象找到記錄它的權威來源。不同類別的問題，權威來源不同：

這張表的用法不是背它，是養成一個反射：看到現象先問「這件事的權威狀態記在哪張表裡」，再去讀那張表，而不是從畫面推測。下面幾個常見的判錯，都是讀了表象而不是權威來源。

讀對權威來源、但查詢條件要對

有時權威來源對了，還是會被誤導——因為查詢的條件寫錯。判程式活著沒，行程表是對的權威、pgrep 是對的工具，但你得比對它實際的行程名：一個程式可能以 symlink 的短名在跑，用你以為的名字 pgrep 就掃不到、誤判成掛了。判服務由誰提供，權威是服務註冊表而非畫面（送一則通知看畫面有沒有跳不可靠——沒跳可能是勿擾吃掉或根本沒送出）。這兩類的具體查法（pgrep -x、busctl 查 D-Bus 擁有者）見 程序、服務與狀態怎麼判。重點是：權威來源對，還要問對地方、用對條件。

卡住是資源問題還是相容問題：先看資源，別先怪相容性

一個耗時的操作中途停住時，很容易直接跳到「是不是這個平台不相容 / 這個東西在這台機器上跑不起來」。但這個結論成本很高（可能讓你放棄一條其實可行的路），而它的權威狀態很好查。一次原始碼編譯跑到一半停住，第一個該看的是資源：df -h 看磁碟是不是滿了、記憶體是不是被吃光——一次實際的案例就是主機磁碟寫滿把編譯中途打斷，清出空間後同一份原始碼接著編就過，跟平台相容性完全無關。先讀資源狀態排除掉最廉價的解釋，再去懷疑相容性這種昂貴的結論。

讀程式自己的 log：從症狀往上游找

當現象是「某個程式行為不對」，它自己的 log 幾乎總是比終端機捲過的畫面更接近真相。很多程式在終端機只印一段摘要，卻同時把詳細執行紀錄寫進一個 log 檔或系統日誌；當畫面上的訊息不足以定位時，那份 log 裡往往就有明確答案。

找 log 的常見去處：程式自己的 log 檔（常在 ~/.local/state/<程式>/ 或 ~/.cache/<程式>/ 底下）、systemd 服務的 journalctl -u <服務名>、或程式啟動時印出的 log 路徑。找到之後，關鍵是用症狀當關鍵字往上游搜——grep -iE 'error|fail|not found|does not exist' <log> 挑出異常行，或在 less 裡用 ?pattern 往回找「第一個」異常（不是停在最後一個下游錯）。一個指令因為前面某個檔案不存在而失敗，終端機可能只報一個看似無關的下游錯誤，但 log 裡會有那句 File does not exist 直指源頭。一個實際案例：某 shell 換了配色卻沒生效，畫面上什麼錯都沒有，是它的 log 裡一句「讀取 scheme 檔失敗：檔案不存在」點出根因——原來那個檔在 shell 啟動當下還沒被建出來。畫面沉默，log 說話。

這一層跟 可除錯的 bootstrap 是一體兩面：那篇談怎麼讓你自己寫的腳本產生一份可診斷的 log，這裡談除錯時怎麼去讀程式自己的 log。兩邊的共同紀律是：不要只盯著終端機捲動，去找那份持久的、詳細的權威紀錄。

遠端除錯反而逼出好紀律

透過 SSH 遠端除錯時，你看不到那台機器的畫面——這個限制反而是好事。看不到畫面，你就沒得靠肉眼猜，只能去讀權威狀態：查 log、查服務註冊、查行程表、查資源。很多在本地會犯的「看畫面就下結論」的錯，在遠端因為根本沒畫面可看而自動被避開。

反過來說，在本地（或看得到畫面的 VM）除錯時，畫面的存在是個誘惑：它讓你以為看到了就懂了。前面那個鎖屏誤判，正是發生在「看得到畫面」的情境——畫面上的密碼框太有說服力，反而蓋過了去讀 log 的動作。把遠端那套「沒有畫面、只信權威狀態」的紀律，也用在本地，就不會被畫面帶偏。

判讀紀律：四步

把上面的東西收成一套每次都能跑的流程：

1. 描述症狀：現象是什麼，先講清楚，不要在這步就急著下結論（「畫面出現密碼框」，不是「螢幕鎖了」）。
2. 定位權威來源：這件事的權威狀態記在哪——log、服務註冊、logind / systemd、行程表、資源用量（用上面那張表對照）。
3. 用對的工具讀它：讀那個權威來源，不是讀畫面、不是讀終端機捲過的殘影。
4. 權威跟表象矛盾時，信權威：如果讀到的權威狀態跟你肉眼的第一印象打架，信權威狀態、回頭修正第一印象——那個矛盾點通常就是你原本會猜錯的地方。

這套流程的價值不在任何單一工具，在於它讓你的判斷有一個可回溯的依據，而不是一串越猜越偏的直覺。

下一步

• 這套心法在遠端連線與終端機情境的應用，見 遠端連線與終端機問題。
• 機器連不到、或根本起不來時怎麼從權威狀態往下查，見 機器連不到或起不來。
• 程序在不在、服務歸誰、狀態怎麼判的具體招式，見 程序、服務與狀態怎麼判。
• 怎麼讓你自己的 bootstrap 腳本產生可讀的 log，見 可除錯的 bootstrap。

SSH「連不上」本身（Permission denied、Host key verification failed、Connection refused）的判讀與修復，見 外部連入與無 key 的 bootstrap 路徑 的重連段落。這篇處理的是「連上了、但終端機或 session 的狀態不對」的那些情況。

SSH 斷線後本機終端機噴亂碼、狂跳字元

一個嚇人但無害的情況：SSH 連線被中斷後，你本機的終端機開始瘋狂輸出像 <35;80;24M 這樣的序列，尤其在你移動滑鼠時狂跳。這不是遠端機器在打字，是你本機的終端機被卡在滑鼠回報模式。

判讀關鍵在「什麼時候噴」：如果那串亂碼只在你移動滑鼠時出現、而且形如 數字;數字M，那就是滑鼠座標回報。成因是遠端跑的某個全螢幕程式（TUI、編輯器、終端機多工器）啟動時對終端機開了滑鼠追蹤模式，SSH 被硬斷時它來不及送出「關閉滑鼠模式」的序列就死了，於是你本機終端機還停在回報模式，滑鼠一動就把游標座標當輸入送進來。

修復是重置終端機的模式，跟遠端機器無關：

• 最快：開一個新的終端機分頁 / 視窗。模式是「那個終端機 session」的狀態，新視窗是乾淨的。
• 救現有視窗：先把滑鼠移開別動（洪流會停），盲打 reset 再 Enter，送出終端機重置。
• 若 reset 沒清掉，補送關閉滑鼠回報的序列：printf '\033[?1000l\033[?1002l\033[?1003l\033[?1006l'。

同一類的還有「alternate screen 沒還原」——遠端的全螢幕程式異常結束時，本機終端機可能卡在替代畫面緩衝區，看起來像畫面清空或凍結。reset 同樣能救。歸納起來：SSH 被硬斷後本機終端機行為異常，先懷疑「對端程式來不及還原終端機模式」，用 reset 或開新視窗處理本機終端機狀態，不必急著重連遠端。

遠端打字變亂碼、重複、位置錯亂

連上遠端後，如果互動式輸入變得不對——打一個字出現好幾個、游標位置錯亂、畫面重繪殘影——通常是兩層問題之一，判讀方式是分開排除。

第一層是字元編碼（locale）。從某些本機（例如 macOS）SSH 進 Linux 時，本機會把 LC_CTYPE 之類的變數帶過去；如果遠端沒有對應的 locale、就會退回 POSIX/C locale，讓終端機的行編輯（ZLE、readline）對多位元組字元的寬度判斷出錯，表現為輸入重複或錯位。判斷方式是在遠端 locale 看目前值、locale -a 看有沒有裝對應的 UTF-8 locale。修法是在遠端明確設好 LANG / LC_CTYPE 到一個實際存在的 UTF-8 locale，而不是讓它繼承一個遠端不認得的值。

第二層是終端機能力資料庫（terminfo）。你本機終端機的 TERM 值（例如某些新終端機用 xterm-ghostty 之類的自訂值）如果在遠端沒有對應的 terminfo 條目，遠端程式就不知道怎麼正確地清行、移動游標、重繪，畫面就會亂。判斷方式是在遠端 echo $TERM 看值、infocmp $TERM 看遠端認不認得。修法是把本機的 terminfo 條目送過去讓遠端安裝：infocmp -x $TERM | ssh <遠端> 'tic -x -'。

先分清是 locale 還是 terminfo，兩者症狀相似但修法不同：locale 是編碼寬度、terminfo 是繪製指令。查 locale 跟查 $TERM + infocmp 就能分開。

從 SSH 操控遠端的圖形桌面

想從一條純文字的 SSH 連線去操作遠端的 Wayland 圖形桌面（例如啟動應用、截圖、送 IPC 指令）時，會撞到兩類界線，判斷對是哪一類就知道怎麼繞。

第一類是圖形程式需要知道連到哪個顯示。SSH 進來的 shell 預設沒有圖形環境的環境變數，直接跑圖形程式會找不到 display。要對著遠端那個已經在跑的 Wayland session 操作，得補上它的環境變數：XDG_RUNTIME_DIR（通常 /run/user/<uid>）、WAYLAND_DISPLAY（socket 名，如 wayland-1）、必要時還有該 compositor 的 instance 變數與 DBUS_SESSION_BUS_ADDRESS。這些值怎麼撈：socket 名用 ls /run/user/$(id -u)/wayland-* 看；其餘變數直接從那個圖形 session 既有行程的環境複製最準——cat /proc/<compositor-pid>/environ | tr '\0' '\n' | grep -E 'WAYLAND_DISPLAY|XDG_RUNTIME_DIR|DBUS_SESSION|_INSTANCE_'（<compositor-pid> 用 pgrep -x Hyprland 之類找）。撈到後 export 進當前 SSH shell，這條連線就能對遠端的圖形 session 下指令、grim 截圖。

第二類是有些東西必須從實體圖形終端機（VT，即 Ctrl+Alt+F1~F6 切換的那些文字主控台）啟動，SSH 的 pty 起不來。Wayland 的合成器（compositor，畫桌面、把視窗合成到螢幕、管輸入輸出的核心程式，如 Hyprland）需要一個真正的圖形 VT 上的登入 session，拿到 DRM master（對顯示卡的獨佔繪圖控制權）與 logind seat（一組綁在一起的實體螢幕／鍵鼠裝置）才能啟動；從 SSH 的 pty 起它的預設 backend 會直接失敗（例如報 backend 建立失敗），因為預設 backend 要的 DRM master 與 seat 在 SSH 這條連線上不存在。判讀訊號：合成器一啟動就報 seat / DRM / backend 相關的錯，而你是從 SSH 起的——那就是這個界線。（例外：合成器多半有 headless backend，例如設 WLR_BACKENDS=headless 就不要 DRM master、不需 VT，專給 CI、雲端、自動化測試用；nested（跑在另一個 Wayland session 裡）也不需要。所以精確說是「預設 backend 需要圖形 VT」，不是「合成器一定起不來」。）

繞法是回到那台機器的實體圖形終端機去啟動 compositor，但「回到 VT」這件事也可以從 SSH 遠端做：

• sudo chvt <N> 從 SSH 切換那台機器目前顯示的虛擬終端機到第 N 個，比在虛擬機視窗裡跟宿主的 Ctrl+Alt+Fn 快捷鍵搏鬥穩定。
• 切過去卻是空白、沒有登入提示，通常是那個 VT 上沒有 getty 在跑：sudo systemctl start getty@tty<N>（開機時 enabled 但 inactive 是常見狀態，logind 的 autovt 沒觸發）。
• sudo fgconsole 確認目前是哪個 VT 在前景。

還有一個容易混淆的點：一台虛擬機可能同時有「序列主控台」跟「圖形顯示」兩個獨立輸出。在 guest 內 chvt 只切圖形那側，序列主控台看到的畫面不會變。如果你在虛擬機軟體裡看的是序列主控台，圖形桌面得切到顯示輸出那個 view 才看得到。判讀：切了 VT 但畫面沒反應，先確認你正在看的是哪個輸出。

判讀路由

遠端 / 終端機問題的分流：

• 本機終端機噴亂碼、只在動滑鼠時噴 → 滑鼠回報模式沒關（本機終端機狀態），reset 或開新視窗。
• 遠端打字重複 / 錯位 → 分 locale（查 locale）與 terminfo（查 $TERM + infocmp）。
• 圖形程式在 SSH 下找不到 display → 補 WAYLAND_DISPLAY / XDG_RUNTIME_DIR 等環境變數。
• compositor 從 SSH 起不來、報 seat/DRM 錯 → 它需要實體 VT，用 chvt + getty@tty<N> 回到圖形 VT 啟動。
• SSH 連不上（拒絕 / host key / refused）→ 見 外部連入與無 key 的 bootstrap 路徑。

這幾種分流的共同底線是先讀權威狀態（locale、$TERM、runtime 目錄、loginctl、fgconsole）再下判斷；背後的方法論見 診斷心法。

遠端機器突然連不上：先分清是哪一段斷

一台昨天還能 SSH 的機器今天連不上，第一步是確認「網路層通不通」，跟「SSH 服務在不在」分開。連線在 TCP 就 timeout（連 port 22 卡住沒回應），多半是網路層或機器沒在跑；連線有回應但被拒（Connection refused），是網路通、但那台機器上沒有服務在聽 port 22。

對虛擬機或同網段的機器，一個很有用的權威來源是鄰居表（IP 對 MAC 的對應）。要填起來需要對方在鏈路層有回應，所以它直接反映「對方在不在」。用 ip neigh 看目標 IP 的條目——優先用 ip neigh 而不是 arp -a，因為 ip（iproute2）在現代最小系統一定有，arp（net-tools）常常沒裝、跑了會 command not found 反而誤導。如果狀態是 INCOMPLETE（arp -a 顯示的是 incomplete），代表這個 IP 在鏈路層上根本沒有機器回應——不是 SSH 的問題，是那台機器的網路沒起來、或根本沒在跑。一個實際案例：一台虛擬機 SSH timeout，鄰居表顯示整個網段的 guest 位址全是 incomplete、只有閘道（宿主那側的橋接介面）是好的——這就定位到「宿主的橋沒問題，但橋的另一頭沒有 VM 在講話」，方向立刻從「調 SSH」轉到「去看 VM 的網路或開機狀態」。

定位到「機器在跑但網路沒起來」後，去那台機器的主控台（不是 SSH，SSH 正是連不上的東西）確認：ip -brief a 看有沒有拿到 IP、systemctl status <網路服務>（dhcpcd / systemd-networkd）看網路服務起了沒，需要時 sudo systemctl restart <網路服務> 重拉。IP 回來、鄰居表的條目從 incomplete 變成有 MAC，就通了。

還有一個常見誤區是 IP 變了。SSH 的別名、金鑰、known_hosts 都綁在特定機器身分上；換機器 / 重裝 / DHCP 重配後 IP 或 host key 變了，用舊別名會連錯或被 host key 檢查擋。這條的判讀與修法（ssh user@新IP 直連、ssh-keygen -R）見 外部連入與無 key 的 bootstrap 路徑。

網路通、但域名解析不了

有一種故障看起來像「網路壞了」，其實是 DNS 解析斷了：能連 IP、卻連不上任何用域名的東西——ping 8.8.8.8 通、但 ping google.com、pacman -Sy、curl https://... 全失敗。判讀要跟前面「網路沒起來」分開，因為網路層是通的，斷的是「域名 → IP」這一步。權威檢查：ping <IP> 通而 ping <域名> 不通、或 getent hosts <域名>（resolvectl query <域名> 若有 systemd-resolved）解不出位址，就定位到 DNS。常見成因是 /etc/resolv.conf 沒有可用的 nameserver（新裝或網路重設後沒填），或負責 DNS 的服務沒起來。修：確認 /etc/resolv.conf 有一行 nameserver（如 nameserver 1.1.1.1）、systemctl status systemd-resolved（若用它）。這一層在剛裝好的最小系統特別常撞到——ip -brief a 明明有 IP，pacman 或 bootstrap 卻抓不到套件，看起來像「網路好好的卻裝不了東西」，根因是 DNS 沒設。

虛擬機開不起來：分清 guest 內部還是宿主側

虛擬機開機失敗時，關鍵判斷是「錯誤來自 guest 內部（作業系統層）還是宿主側（虛擬化軟體 / QEMU 層）」。宿主側的錯誤訊息通常來自虛擬機軟體本身、在 guest 還沒開始開機前就跳出來，跟 guest 裡裝了什麼無關。

一個實例是 QEMU 報「找不到某個 ROM 檔」（例如 efi-virtio.rom）而拒絕啟動。第一反應可能是「檔案不見了要重裝」，但正確的第一步是去確認那個檔在不在——實際去虛擬機軟體的安裝目錄裡找（find <安裝目錄> -name '<rom名>'），會發現 ROM 檔明明就在。既然檔案在，「找不到」就不是缺檔，是 QEMU 執行時在它預期的路徑下找不到——成因隨宿主 OS 不同。在 macOS + UTM 宿主上，最常見的是 Gatekeeper app translocation：帶隔離屬性的 app 被搬到一個隨機唯讀路徑跑，讓 QEMU 解析資源的相對路徑失效，明明存在的檔案在那個執行路徑下就找不到。在 Linux 宿主上（沒有 translocation 這回事），同樣的「找不到 ROM」通常是缺對應套件（ovmf / ipxe-roms / edk2-ovmf）、libvirt XML 指的 ROM 路徑錯、或檔案權限不對——一樣先確認檔在哪、QEMU 是用哪個路徑去找。

另外兩個常見的「VM 起不來」故障也順手一起排除，它們不會特定產生「找不到 ROM」但常伴隨出現：上一次崩潰殘留的 helper 行程卡著（pgrep -af 'qemu|<虛擬機軟體名>' 找，沒清乾淨會佔住資源），以及宿主磁碟滿（df -h，啟動要寫暫存 / 狀態檔）。多數情況下，完全退出虛擬機軟體（連殘留 helper 一起清）+ 清出宿主磁碟空間 + 重新啟動，就恢復了。

判讀通則：虛擬機開不起來，先讀錯誤訊息判斷是 guest 還是宿主側；宿主側報「找不到某資源」而資源其實存在時，往「QEMU 是用哪個路徑找、那條路徑對不對」查（macOS 是 translocation、Linux 是缺套件 / 路徑 / 權限），再順手排除殘留行程與磁碟滿，而不是急著重裝。

磁碟滿是連鎖故障的共同根因

很多看起來各自獨立的故障，共同根因是磁碟滿。磁碟一滿，寫入就會失敗，而系統裡太多東西依賴寫入：SSH session 可能因為寫不了而被斷、正在跑的編譯 / 安裝會中途失敗、log 寫不進去、虛擬機狀態檔存不下導致連不上或開不起來。所以當你在短時間內撞到「連線斷了 + 某個任務失敗 + 服務怪怪的」這種一串症狀時，df -h 應該是很早就要做的檢查——一個廉價的檢查就可能一次解釋掉全部。

這裡有一個容易搞錯的點：清錯了地方。宿主跟 guest 是兩個獨立的檔案系統；虛擬機的宿主磁碟滿，跟 guest 內部磁碟滿，是兩件事。如果你 SSH 進 guest 裡 df 看到還有空間就以為沒事，但真正滿的是宿主的磁碟，那問題不會解決。判讀時要分清這串故障是「哪一台機器的哪個檔案系統」滿了——在宿主上 df -h 看宿主、在 guest 裡 df -h 看 guest，兩邊都要確認。清空間也要清在對的那一側。

判讀路由

• SSH timeout（TCP 卡住）→ 網路層或機器沒跑，查 ip neigh（INCOMPLETE = 對方沒回應）→ 去主控台看 ip -brief a / 網路服務。
• Connection refused → 網路通、但沒有服務在聽 → 去機器上確認 sshd 起了沒。
• 能 ping IP、不能用域名（pacman / curl 失敗）→ DNS 解析問題，查 /etc/resolv.conf 有沒有 nameserver、systemd-resolved 起了沒，不是網路層斷。
• 連錯 / host key 被擋 → IP 或身分變了，見 外部連入與無 key 的 bootstrap 路徑。
• 虛擬機開不起來、宿主側報「找不到資源」但資源在 → 主因查路徑隔離，再排除殘留行程（pgrep -af 'qemu\|...'）/ 磁碟。
• 一串症狀同時發生 → 早點 df -h，宿主與 guest 兩側都查，磁碟滿常是共同根因。

連不上只是最終症狀，真正的定位靠網路表、服務狀態、資源用量這些權威來源一層層往回推——完整的判讀紀律見 診斷心法。

底層的心法（讀權威狀態、不靠肉眼）見 診斷心法，這篇是它在「程序 / 服務 / 狀態」這一類的具體招式。

程式活著沒：比對正確的行程名

判斷一個程式在不在，行程表是權威來源，pgrep / ps 是對的工具，但成敗在於比對正確的行程名（comm，行程表裡記的執行檔短名，可從 /proc/<pid>/comm 看）。一個實際的坑：某個桌面 shell（畫桌面 UI 的圖形程式，不是 bash/zsh 那種命令列 shell）的可執行檔叫 quickshell，但透過名為 qs 的 symlink 啟動時，它在行程表裡的 comm 是 qs。這時 pgrep quickshell 找不到，很容易誤判成程式掛了、甚至誤觸「重啟」而引發更大的問題，實際上它以 qs 這個名字好好跑著。

可靠的做法：

• 先確認實際的 comm 名：ps -eo pid,comm | grep -i <關鍵字>，或看你啟動它的實際指令。
• 用精確比對：pgrep -x <comm>（-x 要求完全相符），或 pgrep -af <pattern> 連完整命令列一起比對，避免被 symlink 名 / 縮寫名騙。
• 另一個 comm 的坑：kernel 把 comm 截在 15 字元（TASK_COMM_LEN），名字超過 15 字的程式用 pgrep -x <完整長名> 反而 miss——這時改用 pgrep -af <pattern> 比對完整命令列。
• 別用一個「你以為的名字」掃過去就下生死結論——行程表沒騙你，是查詢條件寫錯。

進程活著 ≠ 內部子系統活著

比對到了正確的 comm、pgrep 也有輸出，只證明「這個進程存在」，不證明「它內部在正常運作」。有一類故障是進程好端端活著（pgrep 找得到、STAT 是正常的 S、在 poll 等事件、CPU 不高），但它內部某個子系統已經 wedged——例如一個圖形 shell 的 QML scene 因為上游錯誤（渲染 pipeline 建失敗之類）某個物件沒建起來變 null，於是負責互動的模組全部失效。表現是 bar 還畫得出來、卻點不動，keybind 叫不出東西，但焦點視窗打字正常。這時 pgrep 會騙你說「在跑」。

這種情況權威來源不是行程表，是程式自己的 log，而且這種 log 常常不在 journalctl、也不在你猜的路徑，要用該程式專屬的 log 指令（例如某桌面 shell 的 <shell> -l）。log 裡的 TypeError: Cannot read property 'X' of null 這類訊息，才是「進程活著但子系統死了」的定案證據。另一個更精準的活性探針是程式的 IPC 回不回真實狀態：正常時查詢會回傳資料、子系統死掉時回空——這比「進程在不在」可靠得多。判「進程活著到底有沒有在運作」時，讀它自己的 log 與 IPC，不是看 pgrep 有沒有輸出。桌面 shell 的具體案例與恢復（讀 caelestia shell -l 抓到 null 根因、重啟重建 scene）見 常見故障場景與恢復操作 的「畫得出來但互動死掉」場景。

服務由誰提供：問註冊表

「某個系統服務現在由哪個程式在提供」，權威來源是服務註冊，不是畫面。桌面服務多半註冊在 D-Bus（Linux 桌面的行程間訊息匯流排）上：一個服務用一個名字掛在上面，而同一個名字同一時間只能被一個行程擁有。以桌面通知為例，org.freedesktop.Notifications 這個 D-Bus 名同一時間只有一個擁有者——兩個通知 daemon（例如 mako 跟某個桌面 shell 內建的通知服務）不能共存，誰先註冊誰佔著，後者只能等前者退出。

想知道現在是誰接管，查註冊表而不是送一則通知看畫面：

1# 查 org.freedesktop.Notifications 目前被哪個連線擁有
2owner=$(busctl --user call org.freedesktop.DBus /org/freedesktop/DBus \
3  org.freedesktop.DBus GetNameOwner s org.freedesktop.Notifications | awk '{print $2}' | tr -d '"')
4# 把那個連線換算成 PID，再看行程名
5pid=$(busctl --user call org.freedesktop.DBus /org/freedesktop/DBus \
6  org.freedesktop.DBus GetConnectionUnixProcessID s "$owner" | awk '{print $2}')
7ps -o comm= -p "$pid"

停掉舊 daemon 前擁有者是舊的、停掉後換成新的，就確認接管成功。這比「送通知看畫面有沒有跳」可靠——畫面沒跳可能是勿擾模式吃掉、可能根本沒送出，畫面反應不等於服務歸屬。切換兩個搶同一服務名的 daemon 時，這也解釋了為什麼「新的裝了卻沒作用」：舊的還佔著名字，新的靜默註冊失敗（通常只在它的 log 留一行 warning），得先停掉舊的。

桌面 session 有沒有被鎖：認清是哪一層的鎖

判斷一個圖形 session 有沒有被鎖，最容易被畫面帶偏，因為「畫面上有密碼框」很有說服力、卻不等於 session 真的被鎖（現代桌面 shell 的儀表板常內嵌鎖屏樣式的 widget）。而且鎖有不同層，查錯層會得到誤導的答案。

關鍵是分清兩種鎖：

• logind 層的鎖：systemd 登入管理的 session 鎖，權威狀態是 loginctl show-session <id> -p LockedHint。
• Wayland 合成器層的鎖：走 ext-session-lock 協議、由合成器（compositor，Wayland 下負責把各視窗合成到螢幕、管輸入輸出的核心程式，約當 X11 時代的視窗管理器加顯示伺服器；Hyprland、Sway 等都是）管的鎖，跟 logind 是獨立機制。這種鎖 loginctl 的 LockedHint 查不到——不是沒鎖，是查錯層。（用 GNOME / KDE 的鎖屏走的機制不同，以下的 ext-session-lock 判法與復原針對 wlroots 系的 Wayland 合成器。）

所以「loginctl 沒有 LockedHint、pgrep 找不到獨立鎖屏程式」不足以斷定「沒鎖」：合成器層的鎖不歸 logind、而鎖屏畫面可能由 shell 主程式在自己行程內畫（沒有獨立可執行檔可抓）。這種情況真正的權威來源是那個 shell 自己的 log（有沒有載入鎖屏模組、idle 計時器有沒有觸發鎖定），或直接看 compositor 的 session-lock 狀態。判鎖看合成器 / shell 的 log，不是 loginctl、更不是畫面有沒有密碼框。

鎖屏程式死掉造成的死局與復原

ext-session-lock 有一個安全設計：持鎖的鎖屏程式若在鎖定狀態下崩潰 / 被中止，compositor 會保持鎖定、不會因為鎖屏程式沒了就解鎖（否則殺掉鎖屏程式就成了繞過鎖的漏洞）。表現是畫面卡在「鎖屏程式已死」的安全提示。復原要從另一個 VT 或 SSH 用 hyprctl keyword misc:allow_session_lock_restore 1 允許新鎖屏 client 接管、再 hyprctl dispatch exec hyprlock 起一個接管後輸密碼解鎖。完整機制、兩層鎖的關係、各 compositor 的差異，見 Wayland Session Lock 卡。

診斷紀律：測鎖屏、或 pkill 一個持鎖的鎖屏程式時，要預期它把 session 卡在鎖定——這是協議的安全設計，不是 bug。 自動化 / 無人值守流程尤其要避免在持鎖狀態下殺鎖屏程式。

終端機多工器的 session 還在不在

用 zellij / tmux 這類多工器跑遠端長任務時，判斷「重連後那個 session 還在不在」的權威來源是多工器自己的 session 列表，不是「我 SSH 斷了所以應該還在吧」的假設。zellij ls（或 tmux ls）會列出 session 與狀態：多工器是常駐在遠端的程序，SSH 斷不影響它，所以只要那台機器沒重開，attach 就能接回去；但如果機器重開過、或那個 session 因為資源不足（例如磁碟滿觸發的連鎖）被殺，列表會顯示它已 EXITED / 不存在，這種接不回去。

這裡有個順序上的紀律：當一個 session 可能已經死掉、而它裡面跑的任務有你在意的產出時，先確認產出有沒有被安全保存，再處理 session。 例如任務是在改 git repo，先 git -C <repo> status 跟 git log @{u}..（本地有、遠端沒有的 commit）確認有沒有沒推送的東西、把該推的推掉，再去 zellij delete 清死 session。搞反順序、先清了 session，可能連帶失去唯一還記得那些改動的地方。權威狀態（git 的推送狀態、多工器的 session 列表）先讀清楚，再動手。

判讀路由

• 判程式活著 → pgrep -x <正確 comm> / pgrep -af <pattern>，先確認實際 comm 名，別用猜的名字。
• 判進程活著但「有沒有在運作」→ 讀程式自己的 log（可能要用它專屬的 log 指令、不在 journalctl）+ 它的 IPC 回不回真實狀態，不是看 pgrep 有輸出就當正常。
• 判服務歸誰 → busctl 查 D-Bus name 擁有者 → 換算 PID → comm，不看畫面反應。
• 判 session 鎖沒鎖 → 分清 logind 層（loginctl LockedHint）vs 合成器層（ext-session-lock，看 compositor / shell log），不看畫面有沒有密碼框。
• 鎖屏程式死掉卡住 → allow_session_lock_restore + 重起鎖屏程式接管解鎖。
• 判多工器 session 存活 → zellij ls / tmux ls；可能已死且有在意的產出時，先確認產出已保存 / 已推送再清 session。

判不準時，診斷心法 的四步（描述症狀、定位權威來源、用對工具讀、矛盾時信權威）是通用的回退。

理解這個框架後，監控就不是「裝一套很重的東西」，而是分層選擇：從 systemd 內建的失敗鉤子（不裝任何額外服務），到推播管道，到「整台機器死掉」的體外心跳，到完整的指標儀表板。多數人只需要前一兩層。

你現在手動在做的事（要被取代的基線）

在自動化之前，先認清手動版本——這也是所有告警底層讀的同一個權威來源：

1systemctl --failed          # 現在有哪些 unit 處於 failed（開機後系統怪怪的先掃這個）
2systemctl is-failed <unit>  # 單一 unit 明確判失敗（比 is-active 直接）
3journalctl -u <unit> -f     # 即時跟一個 unit 的 log

systemctl --failed 就是「服務死活」的權威清單。手動版的問題不是不準，是你得記得去看。下面每一層都是把「記得去看」換成「壞了它來找你」。

第一層：systemd 原生 OnFailure 鉤子（不裝額外服務）

systemd 每個 unit 進入 failed 狀態時，可以自動觸發另一個 unit。這是最正統、零額外依賴的做法——告警邏輯就寫成一個普通的 systemd service。它由三塊組成：一個負責送通知的處理器 unit、一個實際送出的腳本、以及在你要監控的 unit 上掛一行 OnFailure=。

通知處理器是一個 template unit（@ 表示可帶參數），參數 %i 會是失敗的那個 unit 名：

1# /etc/systemd/system/alert@.service
2[Unit]
3Description=Alert on failure of %i
4[Service]
5Type=oneshot
6ExecStart=/usr/local/bin/notify-failure %i

送出腳本負責把「哪個 unit、在哪台機、什麼時候」推出去。這裡有個實測踩到的坑：在 systemd service 的執行環境下，hostname 指令可能回傳空字串，要改用 uname -n 或讀 /etc/hostname 才穩：

 1#!/bin/bash
 2# /usr/local/bin/notify-failure   （記得 chmod +x）
 3unit="$1"
 4# 只在「真正放棄」時告警：OnFailure 每次失敗都觸發（含 auto-restart 中途，見下節實測），
 5# auto-restart 中途 ActiveState 是 activating、撞重試上限才進 failed。gate 掉中途避免洗告警。
 6state="$(systemctl show "$unit" -p ActiveState --value)"
 7[ "$state" = failed ] || exit 0
 8host="$(uname -n)"                     # 不要用 hostname，systemd 環境下可能回空
 9ts="$(date -Is)"
10topic="你的私密topic"
11curl -fsS \
12  -H "Title: $host: $unit failed" \
13  -d "$unit 於 $ts 進入 failed" \
14  "https://ntfy.sh/$topic"

在要監控的 unit 掛上鉤子。針對單一 unit，加一行：

1[Unit]
2OnFailure=alert@%n.service    # %n 是本 unit 的全名，會展開成 alert@<本unit>.service

要一次套用到所有 service，用 top-level drop-in（放在 service.d/ 這個型別目錄下的設定會套用到每個 .service）：

1# /etc/systemd/system/service.d/onfailure.conf
2[Unit]
3OnFailure=alert@%n.service

改完 sudo systemctl daemon-reload。一個必須注意的遞迴陷阱：全域 drop-in 也會套到 alert@ 自己，它若失敗會觸發自己。給 alert@.service 一個清空 OnFailure= 的 override（[Unit] 段寫 OnFailure=）擋掉。

這條鏈是實測驗證過的：故意讓一個 ExecStart=/bin/false 的測試 service 失敗，systemd log 出現 Triggering OnFailure= dependencies、alert@ 處理器被觸發跑完、curl 推到 ntfy 回 HTTP 200——通知確實送出，全程沒有肉眼介入。

先自動重啟、放棄了才吵你

多數暫時性失敗（一次連線抖動、一個 race）自己重試就好，不值得半夜叫醒你。把「自動復原」跟「告警」分兩段：讓 systemd 先重啟幾次，撐過重試上限才真的算放棄。

1[Service]
2Restart=on-failure
3RestartSec=5
4[Unit]
5StartLimitBurst=3          # 重試 3 次
6StartLimitIntervalSec=60   # 60 秒內都失敗才進 failed（start-limit-hit）

這裡有個實測踩到、跟直覺相反的坑：OnFailure 不是「放棄才觸發」，而是每一次失敗都觸發——包含 Restart=on-failure 的每次 auto-restart 中途。實測一個反覆 crash 的服務（重試 3 次後放棄）觸發了 4 次 OnFailure（3 次 auto-restart + 1 次最終 start-limit-hit）。所以只靠 Restart= + StartLimit= 這段 config，你會被每次瞬斷洗告警。

真正做到「只在放棄才吵」，靠的是上面送出腳本開頭那道 gate：systemctl show <unit> -p ActiveState 在 auto-restart 中途是 activating、撞上限進 failed 才是 failed，腳本只在 failed 才送。加上 gate 後同一個 crash 測試從 4 次告警降到 1 次（只剩最終放棄那次）。config 負責「重試幾次」，handler 的 gate 負責「只在終局告警」——兩段合起來才是完整的「先重啟、放棄才吵」。

抓「進程活著但沒在做事」：外部健康探針

OnFailure 抓的是「進程狀態變了」——crash、exit、被 kill。但服務可能進程還在、卻沒在做事：hung、deadlock、內部子系統壞掉。這種 systemd 看它還 active、不會觸發任何告警——正是「進程活著 ≠ 在運作」那條，搬到監控場景。

要抓這種，得從外面主動戳它、看它回不回應：一個 timer 定時對服務發一個健康請求（HTTP 服務就 curl 它的 /health）並設逾時；戳不動、逾時失敗，就讓「那個檢查」自己 failed，一樣走 OnFailure 告警。

1# health-check.service（oneshot）+ 一個每 2 分鐘跑的 .timer
2[Service]
3Type=oneshot
4ExecStart=/usr/bin/curl -fsS --max-time 5 http://127.0.0.1:8899/health

實測對照最清楚：讓一個健康服務卡在 sleep（進程還在、單執行緒不再回應），systemctl is-active 仍顯示 active——systemd 沒察覺；但這個外部探針 curl /health 5 秒逾時、check 失敗、告警發出。systemd 抓進程死、外部探針抓進程活著但 hung，兩層互補、缺一漏一種。

canary：先證明告警管線本身是好的

監控最怕的失效模式是「出事時才發現它早就不會叫了」。防這個的辦法是養一隻 canary——一個你可控的假服務，專門用來確認整條管線是活的。它一物兩用：

• 驗證管線：故意弄掛它，看「失敗 → OnFailure → 推送」真的一路通到你手機，不必拿 sshd 這種真服務去冒險。
• 當活性訊號：它自己若無故失敗告警，等於告訴你告警系統本身還在運作。

做法是一個極簡 HTTP 服務（stdlib 就夠、不必框架），留幾個測試入口：/health 正常回、/crash 故意退出（測 OnFailure）、/hang 進程活著但不回應（測外部探針）。這樣任何時候都能一鍵重驗監控沒有默默失效。

第二層：推去哪裡（關鍵是能離開這台機器）

處理器腳本裡那一段 curl 可以換成任何管道：

• ntfy（ntfy.sh 或自架）：一行 curl 推到手機，最省事，上面的例子就是。它怎麼運作、公共站 vs 自架、以及「topic 名稱就是唯一的密碼」這個安全模型，見 ntfy：推送通知服務。
• email：要先設好一個 MTA（如 msmtp），腳本改成 mail / sendmail。
• Telegram bot、Apprise（一個工具打多個目標）等。

判準只有一條：告警要送到機器外。送桌面 notify-send 只有你正盯著螢幕時才有用；送手機或 email，離開座位、人在外面也收得到。一台跑正事的機器，告警管道應該落在它之外。

第三層：整台機器死掉怎麼辦（監控自己的盲點）

OnFailure 有個根本限制：它靠 systemd 觸發，機器整台掛了（當機、斷電、kernel panic），systemd 自己都沒了，發不出任何告警。 這是所有「機器自己監控自己」方案的共同盲點——它報得了服務的死，報不了自己這台的死。

覆蓋這一層要反過來做：讓機器定時對一個體外的服務「報平安」，平安訊號一停，由那個體外服務替你告警。這叫 dead-man’s switch（心跳監控）。

1# /etc/systemd/system/heartbeat.service
2[Service]
3Type=oneshot
4ExecStart=curl -fsS https://hc-ping.com/<你的-uuid>
5# 搭配一個 heartbeat.timer，OnUnitActiveSec=5min 定時打

心跳超過設定時間沒到，healthchecks.io（或自架的 Uptime Kuma）就通知你。體內的監控管不了自己這台的死亡，一定要有體外的一隻眼睛——這跟本系列 機器連不到或起不來 是同一個問題的兩面：那篇是機器已經不回應時從外面怎麼查，心跳是讓「不回應」這件事本身自動觸發告警。

第四層：要指標、趨勢、門檻（不只是 up/down）

當你要的不只是「掛了沒」，而是 CPU、記憶體、磁碟、延遲的趨勢與門檻告警（例如磁碟用量超過 80% 就先警告，接上本系列反覆出現的「磁碟滿連鎖」），就進到完整監控堆疊：

這一層不是每個人都需要。單機、只想知道某個服務死活，第一層就夠；要看趨勢、跨機、設門檻，才值得付這層的設定與維運成本。

先確認有沒有，沒有就從最簡單開始

監控最好在出事之前就建好，不是等第一次沒人發現的當機才想到。有兩個時機該主動確認這台機器有沒有在監控自己：裝好一台新機器時，跟發現自己反覆在除同一個服務的失敗時。確認的方式就是讀權威狀態：

1systemctl --failed                      # 現在有沒有 failed 的
2systemctl show sshd -p OnFailure        # 關鍵服務有沒有掛告警鉤子

沒有任何監控的話，從最簡單那層開始建，別一開始就上重的：第一層的 OnFailure + ntfy 就能讓「服務掛了」主動找上你，零額外 daemon、幾個檔案就設好。遠端機器至少把 sshd 掛上——它掛了你就失聯，是最該先監控的一個。等你真的需要趨勢圖、跨機、或告警內容不能經過第三方時，再往自架 ntfy（帳號 + ACL）跟完整監控堆疊爬。多數單機、個人用的情境，停在第一層就夠。

依情境選

把上面四層對回你實際要監控的東西：

• 某個 service 掛了想被通知 → 第一層 OnFailure drop-in + ntfy。不裝額外 daemon，最貼近 systemd。
• 希望先自動重啟、救不回來才告警 → 第一層再加 Restart=on-failure + StartLimit*。
• 怕整台機器當掉沒人知道 → 第三層心跳 / dead-man switch。這層體內方案覆蓋不到，必須體外。
• 要看資源趨勢、跨多台、設門檻告警 → 第四層，單機用 Netdata、多機用 Prometheus 堆疊。

判準是先分清你要監控的層級：單一 service 的死活、整台機器的死活、還是資源的趨勢——三種對應不同層，別拿其中一種去蓋另一種。最常見的誤區是以為體內的 OnFailure 能報自己這台的當機，那正是它的盲點。

下一步

• 告警把你叫來之後，怎麼判那個服務到底是什麼狀態（failed、restart loop、還是活著但子系統 wedged）→ 程序、服務與狀態怎麼判。
• 機器完全不回應、心跳斷掉之後從外面怎麼查 → 機器連不到或起不來。
• 底層那套「讀權威狀態、不靠肉眼猜」的判讀紀律 → 診斷心法。