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

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

判斷一個程式在不在，行程表是權威來源，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。

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

待寫章節

• Health check endpoint 設計（什麼算健康、什麼算不健康、check 的深度）
• Liveness vs Readiness（活著 vs 準備好接流量 — Kubernetes 的兩種 probe）
• systemd watchdog + 自動重啟（WatchdogSec + Restart=on-failure）
• Process supervisor 的選型（systemd / supervisord / Docker restart policy）
• Graceful shutdown（收到 SIGTERM 後的清理流程）

跨分類引用

• → monitoring 模組四 Dashboard DevOps：DevOps dashboard 的服務狀態卡依賴 health check
• → backend 部署平台：部署平台的 health check 整合

理解這個框架後，監控就不是「裝一套很重的東西」，而是分層選擇：從 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）→ 程序、服務與狀態怎麼判。
• 機器完全不回應、心跳斷掉之後從外面怎麼查 → 機器連不到或起不來。
• 底層那套「讀權威狀態、不靠肉眼猜」的判讀紀律 → 診斷心法。