恢復操作解決的是「怎麼讓桌面回來」，日誌判讀解決的是「為什麼會壞掉」。前者是急救，後者是找病因。如果同一個問題反覆出現，只做急救不找根因會一直繞圈。

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 速查

Pattern出處代表什麼下一步
Out of memory: Killed processjournalctl / dmesgOOM Killer 殺了某個 process檢查被殺的 process 名稱、設定 swap 或 systemd-oomd
GPU has fallen off the busdmesgNVIDIA GPU 完全失聯檢查 PCIe 供電、更新 driver、檢查硬體
Xid ... pid=dmesgNVIDIA GPU 錯誤（Xid 編號對應不同類型的錯誤）查 NVIDIA 的 Xid 錯誤代碼表
GPU reset begindmesgAMD GPU driver 嘗試 reset GPU通常會自動恢復，頻繁出現代表 driver 或硬體問題
segfault atjournalctl某個 process segfault（記憶體存取違規）記下 process 名稱，搜尋該軟體的已知 bug
Failed to startsystemctl statussystemd unit 啟動失敗看完整的 status 輸出和 journalctl log 找原因
config error / parse error各工具自身的 logConfig 檔語法錯誤檢查最近改過的 config 檔

排查流程

這篇是 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 插槽接觸、供電、溫度）。