本文用「桌面環境」泛指使用者看到的圖形介面整體。技術上，Hyprland 是 Wayland compositor——負責視窗合成和輸入管理，不含完整桌面環境（DE）的套件管理、設定面板等元件。GNOME、KDE Plasma 才是完整的 DE。但在故障隔離的討論中，關鍵區分是 kernel space vs userspace，compositor 和 DE 都在 userspace 這一側。

Kernel 與 Userspace 的隔離邊界

作業系統分成兩個執行空間。Kernel space 負責硬體驅動、記憶體管理、process 排程這些基礎設施。Userspace 跑所有應用程式，包括桌面環境本身。

兩個空間之間有硬體層級的隔離——CPU 的保護環機制（ring 0 是核心層級、ring 3 是應用程式層級，硬體強制限制 ring 3 的程式碼存取 ring 0 的記憶體）。Userspace 的 process 不管怎麼崩潰，都不會直接影響 kernel。Kernel 會清理掉崩潰的 process、回收它佔用的記憶體，然後繼續運作。

這個隔離機制解釋了一個關鍵差異：為什麼 Linux 上一個 app crash 通常只是那個視窗消失，而不會拖垮整台機器。

為什麼 Windows 會藍屏

Windows 的藍屏（Blue Screen of Death, BSOD）是 kernel panic 的表現——作業系統核心本身遇到無法恢復的錯誤，只能停機。

Windows 藍屏頻率較高的結構性原因在於顯示驅動的執行位置。Windows 把 GPU 驅動放在 kernel mode（WDDM 架構），NVIDIA 或 AMD 的驅動程式碼直接跑在核心空間。驅動有 bug 時，錯誤發生在 kernel space，清理掉再繼續的選項不存在——繼續執行可能造成資料損壞，只能停機。

藍屏頻率高是架構選擇的代價。把驅動放在 kernel mode 可以減少 context switch 的效能開銷，GPU 效能更好。代價是驅動 bug 的爆炸半徑從「app crash」升級成「整台停機」。Windows 10/11 已加入 TDR（Timeout Detection and Recovery）機制——GPU driver hang 時系統嘗試 reset driver 而非直接藍屏，大幅降低了 GPU 導致的 BSOD 頻率。但架構上 driver 仍在 kernel mode，藍屏的可能性仍然存在。

Linux 桌面的架構差異

Linux 桌面環境的顯示合成器（Hyprland、Sway、KDE Plasma 的 KWin）跑在 userspace。它們透過 DRM/KMS（Direct Rendering Manager / Kernel Mode Setting，Linux 的顯示子系統介面）跟 kernel 的 GPU 驅動溝通，但合成器本身的程式碼不在 kernel space 裡。

這個架構選擇的效果：

Compositor crash。Hyprland 如果遇到 segfault 或其他 fatal error，kernel 終止這個 userspace process。所有由它管理的視窗消失，螢幕回到 TTY 登入畫面或黑屏。但 kernel 還在跑——其他 TTY 可以登入，SSH 可以連線，背景的 service 繼續運作。

GPU driver bug。Linux 的 GPU 驅動分兩層：kernel module（可動態載入的核心擴充模組，如 nvidia.ko、amdgpu.ko）負責硬體操作，userspace 的 Mesa / NVIDIA userspace driver 負責 OpenGL/Vulkan 實作。Kernel module 出問題理論上可以 kernel panic，但實際行為取決於驅動。AMD 的開源 amdgpu 通常會嘗試 reset GPU 而非直接 panic，常見的表現是畫面凍結幾秒後恢復。NVIDIA 的閉源 nvidia.ko 是隔離模型的主要例外——kernel 社群無法審查或修復其程式碼，hang 時恢復能力遠弱於 amdgpu，經常拖垮整個 session 且 TTY 切換也受影響。這是後續故障場景中 NVIDIA 相關 caveat 的根源。

應用程式 crash。Firefox、VS Code、任何 GUI 程式崩潰，只有那個視窗消失。Compositor 繼續管理剩下的視窗，桌面環境不受影響。

TTY：kernel 存活時的首選救生通道

TTY（TeleTYpewriter）是 Linux 核心直接提供的純文字終端機介面，獨立於任何桌面環境。systemd 預設配置下有 6 個 virtual console（TTY1-TTY6）。Wayland compositor（如 Hyprland）通常佔用 TTY1，其餘可用。

切換方式：Ctrl+Alt+F2（切到 TTY2）到 Ctrl+Alt+F6（切到 TTY6）。

TTY 的重要性在於它不依賴 compositor。Hyprland 掛了、compositor crash 導致桌面消失——只要 kernel 還活著、GPU driver 仍能處理 VT switch，TTY 就能切過去登入操作：

• 用 htop 或 ps 查看哪個 process 出問題
• kill 有問題的 process
• 用 vim 或 nano 修改配置檔
• 重新啟動 Hyprland（Hyprland 指令）
• 如果需要，正常 reboot

TTY 切換失效的情境有兩種：kernel panic（極罕見）和 GPU 完全 hang 導致 VT switch 本身卡住（NVIDIA 閉源驅動在 Wayland 上較常見，需確保 nvidia_drm.modeset=1）。後者的替代手段是 SSH 遠端登入或 Magic SysRq 鍵（見常見故障場景的場景三）。

記憶體耗盡（OOM）的處理機制

Linux kernel 有 OOM Killer（Out of Memory Killer）機制——當記憶體和 swap 都用完、kernel 無法再分配新頁面時，自動挑選佔用記憶體最多、重要性最低的 process 強制終止，釋放記憶體讓系統繼續運作。

OOM Killer 的行為有時超出使用者的預期——它可能直接終止 Hyprland（因為 compositor 通常佔用不少記憶體），導致桌面突然消失。但關鍵是：系統沒有崩潰。Kernel 還在、TTY 還在、SSH 還在。

預防 OOM 的常見做法：

• 設定 swap（即使用 SSD，2-4GB 的 swap 也能在記憶體壓力大時提供緩衝）
• 啟用 systemd-oomd（userspace 的 OOM 管理，比 kernel OOM Killer 更早介入、更可控）
• 監控記憶體用量（btop 或 htop 可以看即時狀態）

故障層級速查

前五個層級都有恢復手段，只有 kernel panic 需要重開機。日常使用中遇到的故障多數落在前三層。

場景一：Hyprland compositor crash

症狀：所有視窗同時消失，螢幕變黑或回到 TTY 登入畫面。滑鼠鍵盤有反應（可以切 TTY），但沒有桌面。

原因：Compositor process 遇到 fatal error 被 kernel 終止。常見觸發條件包括 plugin 相容性問題、特定 Wayland 協議操作觸發的 bug、GPU driver 回傳異常狀態。

恢復步驟：

注意：以下步驟中 killall Hyprland 或重啟 Hyprland 會終止所有由 compositor 管理的視窗，未存檔的工作會遺失。如果可能，先透過 TTY 或 SSH 嘗試存檔（如 kill -USR1 <pid> 對支援的應用程式觸發存檔）。

1. Ctrl+Alt+F2 切到 TTY2
2. 用你的帳號登入
3. 檢查 Hyprland 的最後錯誤訊息：

1# 通用方式（不管 Hyprland 怎麼啟動都有效）
2journalctl -b | grep -i hypr | tail -30
3
4# 如果 Hyprland 是 systemd user unit，可以更精準地查：
5journalctl --user -u hyprland -n 50 --no-pager

4. 重新啟動 Hyprland：

1Hyprland

5. 如果反覆 crash，檢查最近改過的 config：

1cd ~/.config/hypr
2git diff  # 如果 dotfile 有版控

預防：config 改動後用 hyprctl reload 測試，不要直接重啟。啟用 plugin 前確認版本跟 Hyprland 版本相容。

場景二：單一桌面工具掛了

症狀：狀態列（waybar）消失、啟動器（wofi/rofi）叫不出來、通知（mako/dunst）不跳了。桌面其他功能正常，視窗可以操作。

原因：這些工具各自是獨立的 process。掛了只影響自己的功能，不影響 compositor 或其他工具。常見原因是 config 語法錯誤（改完 config 後觸發）、記憶體洩漏（長時間運作後）、或外部服務連線異常（如 waybar 的某個 module 連不到系統匯流排）。

恢復步驟：

判斷啟動方式：如果工具是在 Hyprland config 裡用 exec-once（Hyprland 的自動啟動指令，compositor 啟動時執行一次）啟動的，用 killall + 手動重啟；如果是 systemd user unit，用 systemctl --user。

exec-once 啟動方式（多數 Hyprland 安裝的預設做法）：

1# waybar 掛了
2killall waybar; waybar &
3
4# wofi 掛了
5killall wofi
6# wofi 只在需要時啟動，不用常駐
7
8# mako 掛了
9killall mako; mako &

systemd user unit 啟動方式：

1systemctl --user restart waybar
2systemctl --user restart mako

確認工具是否在跑：

1pgrep waybar  # 有輸出 = 在跑
2pgrep mako    # 沒輸出 = 沒在跑

預防：改 config 後重啟對應的工具確認語法正確。Waybar 的 config 是 JSON 格式，語法錯誤會導致它無法啟動——改完後先用 waybar 前台跑一次看有沒有錯誤訊息。

場景二點五：鎖屏卡死（hyprlock 異常結束）

症狀：鎖屏畫面消失但桌面沒回來，螢幕顯示 Hyprland 的失效保護訊息（「it looks like you locked your screen but the lockscreen app died」），或畫面全黑但系統有回應（SSH 能連、TTY 可能切得到也可能切不到）。

原因：鎖屏工具（Hyprlock、Swaylock）透過 Wayland 的 ext-session-lock 協議向 compositor 請求鎖定。鎖定狀態由 compositor 持有，唯一正常解鎖動作是鎖屏 client 通過認證後呼叫 unlock_and_destroy。如果鎖屏 client 在持鎖狀態下被殺（pkill、crash），compositor 沒收到認證信號，會維持鎖定並顯示失效保護畫面。這跟殺 waybar/mako 不同——那些是普通 process，殺了重啟就好；鎖屏 client 持有安全狀態，殺了反而卡住。

恢復步驟：

1. 嘗試切到另一個 TTY（Ctrl+Alt+F2）。注意：ext-session-lock 的安全語意允許 compositor 攔截 VT 切換快捷鍵，此時 TTY 切不過去，改用 SSH 從另一台機器連入
2. 允許新的鎖屏 client 接管既有的鎖：

1hyprctl --instance 0 'keyword misc:allow_session_lock_restore 1'

3. 重新拉一個鎖屏 client：

1hyprctl --instance 0 'dispatch exec hyprlock'

4. 回到鎖屏畫面，用密碼正常解鎖

判讀：loginctl show-session <id> -p LockedHint 可能顯示 LockedHint=no（logind 層認為沒鎖），但畫面仍進不去——因為擋住畫面的是 compositor 的 ext-session-lock，跟 logind 的提示是獨立的兩層。判斷畫面鎖定狀態看 compositor 層，不看 logind。

預防：測試鎖屏時備好恢復路徑（知道密碼、或預先開 SSH）。不要用殺 process 的方式結束鎖屏——要結束就走認證解鎖。自動化流程若會啟動鎖屏，把「需要人工解鎖」算進代價。鎖屏安全模型的完整說明見 Session Lock。

場景二點六：桌面 shell 畫得出來但互動死掉（進程活著卻 wedged）

症狀：bar / 狀態列還在螢幕上、看起來一切正常，但點它的按鈕（工作區切換、系統匣圖示）沒反應，keybind 叫不出啟動器（wofi / 內建 launcher）。同時焦點視窗（例如終端機）打字完全正常——鍵盤到得了應用程式，只是桌面 shell 的互動死了。

原因：這是跟場景二（工具掛了）不同的一類故障，關鍵差別在進程還活著。場景二是 process 崩潰退出（pgrep 沒輸出），殺了重啟就好；這裡的桌面 shell（如 caelestia / Quickshell）進程還在跑（pgrep 找得到、STAT 是正常的 S、在 poll 等事件、CPU 不高），但它內部的某個子系統初始化失敗了——常見是 QML scene 的某個物件因為上游錯誤沒建起來、變成 null，於是負責「keybind → 開抽屜」「bar 按鈕互動」的模組對 null 讀屬性、整條互動接線死掉。bar 之所以還畫得出來，是它還停在初始化失敗前那一幀的畫面：畫得出來不等於還活著，跟鎖屏那課（畫面有密碼框不等於真的在鎖）是同一個陷阱。

上游觸發常是渲染層。實測案例：VM 的 GPU 只提供到 GLSL 1.20，而 shell 的 shader 需要 GLES 100/300/330，pipeline 建不起來（log 狂噴 Failed to build graphics pipeline state），這次渲染失敗把 scene 初始化打斷，drawers 狀態物件變 null。

診斷（別看 pgrep，讀 shell 自己的 log）：

pgrep 在這裡會騙你——它回報「在跑」，但那不等於「在運作」。權威來源是 shell 自己的 log，而且這種 log 常常不在 journalctl、也不在你猜的路徑，要用該 shell 專屬的 log 指令：

1# caelestia 的例子：用它自己的 CLI 印 shell log
2caelestia shell -l 2>&1 | tail -40
3# 看的是 QML 的 TypeError：對 null 讀屬性 = 那個子系統死了
4#   scene: @modules/Shortcuts.qml: TypeError: Cannot read property 'launcher' of null

另一個活性探針是 shell 的 IPC 回不回真實狀態：正常時查抽屜列表會回傳名字，子系統死掉時回空——這比「進程在不在」精準得多：

1# 子系統活著 → 列出 bar/launcher/session…；死掉 → 回空
2caelestia shell ipc call drawers list

恢復步驟：重啟 shell 讓 scene 重建。以 caelestia 為例：

1caelestia shell -k     # 殺掉卡住的 shell
2caelestia shell -d     # 重新啟動（detached）

驗證修好了，看子系統回來、不是看 pgrep：重啟後 process 一定在（pgrep 本來就會有），要確認的是接線恢復——caelestia shell ipc call drawers list 從「回空」變成列出真實抽屜名、log 不再噴 null 的 TypeError。這對應「重啟成功要驗子系統狀態、不是驗 process 存在」的通用紀律。

判讀與其他場景的界線：pgrep 有輸出 + bar 畫得出來 → 別急著判「正常」；點不動 / keybind 死掉就是 wedged 的訊號，往 shell 自己的 log 查。這跟場景二（process 真的沒了、pgrep 空）、場景三（compositor 整個凍結、連終端機打字都不行）都不同——這裡 compositor 正常、焦點視窗鍵盤正常，只有 shell 的互動接線死。判「進程活著到底有沒有在運作」的通用招式，見 程序、服務與狀態怎麼判。

預防：留意 shell log 裡持續出現的 shader / 渲染 pipeline 錯誤——在 VM 或 GL 支援不足的環境，這類錯誤可能非致命地存在（shell 大致能用），但一次渲染失敗就可能打斷 scene 初始化、把互動接線弄死。VM 環境要確認 GPU 提供的 GL / GLSL 版本足夠（virtio-gpu 走 mesa/zink 提供 GL 3.3+），或在 shell 設定關掉需要高階 shader 的效果。

場景三：GPU driver hang（畫面凍結）

症狀：桌面畫面完全凍結——滑鼠不動、鍵盤不回應、Ctrl+Alt+F2 切 TTY 也沒反應或延遲很久才回應。但如果從另一台機器 SSH 進來，系統是活的，process 都在跑。

原因：GPU driver 進入異常狀態。NVIDIA 閉源驅動在 Linux 上的穩定性不如 AMD 開源驅動（amdgpu），特別是在 Wayland 環境下。常見觸發條件包括 suspend/resume 之後 GPU 沒正確恢復、某些 OpenGL/Vulkan 操作觸發 driver bug、顯示輸出切換（接上或拔掉外接螢幕）。

恢復步驟：

方法 A — 如果 TTY 能切過去：

1# 切到 TTY2
2Ctrl+Alt+F2
3
4# 殺掉 Hyprland（它會帶走所有視窗）
5killall Hyprland
6
7# 重新啟動
8Hyprland

方法 B — 如果 TTY 也凍結、但 SSH 能連：

 1# 從另一台機器 SSH 進來（需事先知道 IP，見下方預防段）
 2ssh user@machine-ip
 3
 4# 殺掉 compositor
 5killall Hyprland
 6
 7# 如果需要 reset GPU（NVIDIA，且 driver 仍回應）
 8# 前提：所有使用 GPU 的 process 已停止（compositor 已 kill）
 9sudo nvidia-smi --gpu-reset
10
11# 切回機器前面重啟 Hyprland

方法 C — 如果完全無回應，先嘗試 Magic SysRq：

Magic SysRq 是 kernel 層級的緊急操作介面，即使 userspace 完全卡死也能回應。按住 Alt+SysRq（筆電通常是 Alt+Fn+SysRq），然後依序按 R E I S U B（每個鍵間隔幾秒）：

• R — 把鍵盤從 raw mode 搶回來
• E — 對所有 process 送 SIGTERM
• I — 對所有 process 送 SIGKILL
• S — sync 所有檔案系統
• U — remount 所有檔案系統為 read-only
• B — 立即 reboot

這比直接斷電安全——sync + unmount 步驟會盡量保護磁碟上的資料。Arch Linux 預設可能停用 SysRq，需在 /etc/sysctl.d/ 設定 kernel.sysrq=1 啟用。

方法 D — 如果 SysRq 也無效，按住電源鍵強制關機：

這是最後手段。Linux 的 ext4/btrfs 檔案系統有 journal 保護，強制關機通常不會損壞檔案系統結構。但 journal 保護的是 metadata 一致性，正在寫入的使用者資料（未存檔的文件、正在下載的檔案）仍然可能遺失或損壞。重開機後正常登入 TTY、啟動 Hyprland 即可。如果開機過程有異常，用 journalctl -b -1 -p err 查看上次開機的錯誤訊息，確認是否有檔案系統修復紀錄。

預防：

• NVIDIA 用戶：關注 driver 版本的 release notes，已知有 Wayland 問題的版本避開
• 配置 suspend 後的 GPU 恢復：在 Hyprland config 或 systemd sleep hook 裡加入 GPU reset 操作
• 事先記錄機器的 IP 位址（ip addr show）或設定固定 hostname（如 mDNS 的 machine.local），桌面凍結時才有辦法從另一台機器 SSH 進來
• 考慮開啟 SSH server，出問題時可以遠端救援。開啟後應配置 key-based authentication 並停用密碼登入（PasswordAuthentication no），避免在網路上暴露密碼登入通道：

1sudo systemctl enable sshd
2sudo systemctl start sshd
3
4# 安全配置：停用密碼登入（確保已設好 SSH key 再改）
5# 編輯 /etc/ssh/sshd_config，設定 PasswordAuthentication no
6# 然後 sudo systemctl restart sshd

場景四：記憶體耗盡（OOM）

症狀：系統變得極慢，操作有明顯延遲（幾秒到幾十秒）。隨後可能某些 process 突然被殺掉——瀏覽器分頁消失、IDE 視窗關閉，嚴重時 Hyprland 本身被 OOM Killer 終止導致桌面消失。

原因：實體記憶體和 swap 都用完了。常見觸發者是瀏覽器（Chrome/Firefox 的分頁越開越多）、IDE（大型專案的 language server）、Docker container、或應用程式的記憶體洩漏。

恢復步驟：

如果還能操作：

1# 找出誰在吃記憶體
2top -o %MEM
3# 或用 htop/btop 的互動介面
4
5# 殺掉佔最多記憶體的 process
6kill <PID>

如果桌面已經被殺、在 TTY 裡：

1# 看 OOM Killer 殺了誰
2journalctl -b | grep -i "out of memory"
3journalctl -b | grep -i "oom"
4
5# 清理完後重啟桌面
6Hyprland

預防：

設定 swap（即使 RAM 夠大，swap 提供 OOM 前的緩衝時間讓你有機會手動清理 process）。RAM 16GB 以上的機器，2-4GB swap 作緩衝通常足夠：

 1# 查看是否有 swap
 2swapon --show
 3
 4# 如果沒有，建立一個 4GB 的 swap file（ext4 檔案系統）
 5sudo fallocate -l 4G /swapfile
 6sudo chmod 600 /swapfile
 7sudo mkswap /swapfile
 8sudo swapon /swapfile
 9
10# 永久生效：加入 /etc/fstab
11echo '/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab

Btrfs 檔案系統不支援 fallocate 建立 swap file。Btrfs 用戶需改用 btrfs filesystem mkswapfile 或建立專屬的 swap subvolume，具體做法參考 Arch Wiki 的 Btrfs swap 段落。

啟用 systemd-oomd（比 kernel OOM Killer 更早介入、更可控）。systemd-oomd 在 cgroup 的記憶體壓力達到閾值時就開始清理，預設配置對多數桌面場景足夠。進階調整可透過 /etc/systemd/oomd.conf 設定：

1sudo systemctl enable systemd-oomd
2sudo systemctl start systemd-oomd

場景五：Config 寫錯導致 Hyprland 啟動失敗

症狀：從 display manager（圖形登入畫面，如 SDDM、GDM）登入後立刻黑屏又回到登入畫面，或直接回到 TTY。如果從 TTY 手動執行 Hyprland，看到錯誤訊息後立即退出。

原因：Hyprland config 有語法錯誤或引用了不存在的資源。常見錯誤包括 source 指定的檔案不存在、keybind 語法寫錯、monitor 設定格式錯誤。

恢復步驟：

1. 切到 TTY（Ctrl+Alt+F2）
2. 登入後直接跑 Hyprland 看錯誤訊息：

1# 看 Hyprland 的啟動錯誤（也可用 journalctl -b | grep -i hypr）
2Hyprland
3# Hyprland 如果因 config 錯誤無法啟動，會直接印出錯誤訊息後退出

3. 根據錯誤訊息修改 config：

1# Hyprland 的主 config
2vim ~/.config/hypr/hyprland.conf
3
4# 如果用了 source 拆分，錯誤訊息會指出是哪個檔案
5vim ~/.config/hypr/keybinds.conf

4. 修完後重新啟動：

1Hyprland

常見 config 錯誤：

source 路徑錯誤——檔案不存在或路徑拼錯：

1# 確認 source 指定的檔案都存在
2grep "^source" ~/.config/hypr/hyprland.conf
3# 逐一檢查每個路徑

Monitor 設定錯誤——指定了不存在的螢幕名稱：

1# 查看系統實際的螢幕名稱
2# 在能進桌面時記下來，或用 wlr-randr
3wlr-randr

Keybind 語法錯誤——dispatcher 名稱拼錯或參數格式不對。Hyprland 的 keybind 格式是 bind = MOD, key, dispatcher, params，少一個欄位或 dispatcher 拼錯就會報錯。

預防：config 改動時用 hyprctl reload 即時測試，不要改完 config 就直接重啟 Hyprland。如果 dotfile 用 Git 管理，改壞了可以 git checkout 回退。

場景六：Suspend/resume 後桌面異常

症狀：筆電蓋上或手動 suspend 後喚醒，出現以下任一情況——螢幕黑屏但系統有反應（鍵盤背光亮）、解析度跑掉、多螢幕配置丟失（所有視窗擠到一個螢幕）、compositor 直接 crash 回到 TTY。

原因：GPU driver 在 suspend/resume 過程中需要保存和恢復 GPU 狀態。NVIDIA 閉源驅動在 Wayland 上的 suspend/resume 支援不如 AMD 開源驅動穩定，特別是多螢幕配置和高刷新率模式下容易出問題。

恢復步驟：

如果螢幕黑屏但系統有反應：

1# 切到 TTY
2Ctrl+Alt+F2
3
4# 檢查 Hyprland 是否還在跑
5pgrep Hyprland
6
7# 如果在跑但沒畫面，kill 再重啟
8killall Hyprland
9Hyprland

如果解析度或螢幕配置跑掉：

1# 在 Hyprland 內重新套用 monitor 設定
2hyprctl reload

如果 compositor 已經 crash：按場景一的步驟從 TTY 重啟。

預防：

• NVIDIA 用戶：在 /etc/modprobe.d/nvidia.conf 啟用 preserve video memory allocations：

1# /etc/modprobe.d/nvidia.conf
2options nvidia NVreg_PreserveVideoMemoryAllocations=1

同時啟用 NVIDIA 的 suspend/resume systemd service：

1sudo systemctl enable nvidia-suspend
2sudo systemctl enable nvidia-resume
3sudo systemctl enable nvidia-hibernate

• AMD 用戶：amdgpu driver 的 suspend/resume 通常開箱即用，遇到問題先更新 kernel（pacman -Syu linux）。

journalctl：系統日誌的主要入口

systemd 的日誌系統（journal）集中收錄所有 service、kernel、user session 的 log。journalctl 是查詢這些日誌的指令。

基本用法

 1# 本次開機的所有日誌
 2journalctl -b
 3
 4# 本次開機的錯誤以上等級（err + crit + alert + emerg）
 5journalctl -b -p err
 6
 7# 本次開機，只看最後 50 行
 8journalctl -b -n 50
 9
10# 上一次開機的日誌（如果問題發生在上次開機、這次重開後想查）
11journalctl -b -1
12
13# 即時跟蹤新 log（類似 tail -f）
14journalctl -f

過濾特定來源

 1# 只看 Hyprland 相關
 2journalctl -b | grep -i hypr
 3
 4# 只看特定 systemd user unit
 5journalctl --user -u waybar -b
 6
 7# 只看 kernel 訊息（等同 dmesg）
 8journalctl -b -k
 9
10# 只看某個 process 的 log（用 PID）
11journalctl _PID=12345

時間範圍過濾

1# 最近 10 分鐘的 log
2journalctl --since "10 min ago"
3
4# 指定時間區間
5journalctl --since "2026-06-30 14:00" --until "2026-06-30 14:30"

dmesg：Kernel 層訊息

dmesg 顯示 kernel ring buffer 的內容——硬體偵測、driver 載入、硬體錯誤這些 kernel 層面的事件。排查 GPU driver 問題、USB 裝置問題、磁碟錯誤時需要看這裡。

 1# 所有 kernel 訊息（帶時間戳記）
 2dmesg -T
 3
 4# 只看錯誤和警告
 5dmesg -T --level=err,warn
 6
 7# GPU 相關（NVIDIA）
 8dmesg -T | grep -i nvidia
 9
10# GPU 相關（AMD）
11dmesg -T | grep -i amdgpu
12
13# USB 相關（鍵盤滑鼠突然不回應時看這裡）
14dmesg -T | grep -i usb

GPU driver 問題在 dmesg 裡的嚴重度差異很大：

一般 GPU hang（driver 嘗試自動恢復）：

1[  123.456] nvidia-modeset: ERROR: ...
2[  123.789] NVRM: Xid (PCI:0000:01:00): 79, pid=1234, ...
3[  124.000] amdgpu: GPU reset begin!
4[  124.500] amdgpu: GPU reset succeeded

NVIDIA 的 Xid 錯誤代碼表示不同類型的 GPU 錯誤。常見的 Xid 79 是 GPU fallback，Xid 31 是 GPU setup failure。完整代碼表可在 NVIDIA 官方文件搜尋「Xid Errors」。

硬體層級故障（嚴重，可能需要檢查硬體）：

1[  123.789] NVRM: Xid (PCI:0000:01:00): 79, pid=1234, GPU has fallen off the bus

GPU has fallen off the bus 表示 GPU 跟主機板的 PCIe 連線完全中斷。偶發一次可能是 driver 問題，反覆出現通常是硬體故障（PCIe 供電不足、顯卡接觸不良、過熱）。

hyprctl：Hyprland 的 Runtime 狀態查詢

hyprctl 是 Hyprland 提供的命令列控制工具，可以在 compositor 運行中查詢狀態和執行操作。只有在 Hyprland 正在跑的時候才能使用。

 1# 目前所有視窗的資訊
 2hyprctl clients
 3
 4# 目前的 monitor 設定
 5hyprctl monitors
 6
 7# 目前的 workspace 資訊
 8hyprctl workspaces
 9
10# Hyprland 版本和 build 資訊
11hyprctl version
12
13# 重新載入 config（不重啟 compositor）
14hyprctl reload
15
16# 查看上一次 config reload 是否有錯誤
17hyprctl systeminfo

hyprctl reload 是測試 config 變更的安全方式。如果 config 有語法錯誤，reload 會報錯但 compositor 繼續用舊 config 跑，不會崩潰。

systemctl：Service 狀態管理

桌面環境的工具（waybar、mako 等）如果用 systemd user unit 管理，可以用 systemctl --user 查看狀態和重啟。

 1# 查看某個 user service 的狀態
 2systemctl --user status waybar
 3
 4# 輸出範例：
 5# waybar.service - Highly customizable Wayland bar
 6#    Loaded: loaded (/usr/lib/systemd/user/waybar.service; enabled)
 7#    Active: active (running) since Mon 2026-06-30 10:00:00 CST
 8#    Main PID: 1234 (waybar)
 9
10# 重啟
11systemctl --user restart waybar
12
13# 看最近的 log
14systemctl --user status waybar -n 20

如果這些工具不是 systemd unit（在 Hyprland config 裡用 exec-once 啟動的），就不能用 systemctl 管理。改用 pgrep 和 kill：

1pgrep waybar      # 查看是否在跑
2killall waybar    # 停止
3waybar &          # 背景啟動

即時資源監控

排查效能問題和記憶體耗盡時，需要看即時的系統資源使用情況。

htop：互動式 process 監控。按 M 可以按記憶體用量排序，按 P 按 CPU 排序。找到佔用異常的 process 後按 F9 可以直接 kill。

btop：功能更豐富的替代品，顯示 CPU、記憶體、磁碟、網路的即時使用情況，圖形化介面比 htop 直觀。

1# 安裝
2sudo pacman -S btop    # Arch
3sudo apt install btop  # Debian/Ubuntu
4
5# 執行
6btop

nvidia-smi：NVIDIA GPU 的專屬監控工具。顯示 GPU 使用率、記憶體、溫度、跑在上面的 process。

1# 一次性查看
2nvidia-smi
3
4# 持續監控（每 2 秒更新）
5nvidia-smi -l 2

常見 Log Pattern 速查

排查流程

這篇是 Hyprland 桌面的具體日誌工具；背後「先讀權威狀態、不靠肉眼猜」的通用診斷心法（每種問題的權威來源、四步流程），見 Linux 除錯與診斷：診斷心法。遇到桌面環境問題時的判讀順序：

1. 判斷影響範圍：只有一個視窗壞了、某個工具壞了、整個桌面壞了、還是系統完全不回應？影響範圍決定要看哪一層的 log。

2. 看 journalctl：journalctl -b -p err 先看本次開機有沒有錯誤等級的訊息。大部分 userspace 的問題（compositor crash、工具 crash）會出現在這裡。

3. 看 dmesg：如果 journalctl 沒有明顯線索、或症狀跟硬體有關（畫面凍結、USB 不回應），dmesg -T --level=err,warn 看 kernel 層有沒有硬體或 driver 錯誤。

4. 查特定工具的狀態：systemctl --user status <tool> 或 pgrep <tool> 確認工具是否還活著。如果死了，看它最後的 log 訊息。

5. 即時監控：如果問題是漸進式的（越來越慢、偶爾卡頓），開 btop 或 htop 觀察 CPU 和記憶體的即時趨勢，找出佔用異常的 process。

找到問題後的下一步

判讀完 log 確認問題類型後，行動路徑依問題性質分流：

• Config 錯誤：直接修 config，用 hyprctl reload 或重啟工具驗證。操作步驟見常見故障場景與恢復操作。
• 軟體 bug（segfault、特定操作觸發 crash）：到該軟體的 issue tracker（通常在 GitHub）搜尋錯誤訊息。Hyprland 的 issue tracker 在 github.com/hyprwm/Hyprland。回報 bug 時附上 hyprctl systeminfo 的輸出和相關的 journalctl log。
• GPU driver 問題：NVIDIA 用戶檢查是否有更新的 driver 版本（pacman -Syu nvidia）。AMD 用戶的 driver 跟 kernel 綁定，更新 kernel 就更新 driver（pacman -Syu linux）。
• 硬體故障（GPU has fallen off the bus 反覆出現）：軟體層面無法解決，需要檢查硬體（PCIe 插槽接觸、供電、溫度）。