日誌判讀與診斷工具

Tue, 30 Jun 2026 00:00:00 +0000

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

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 process`	journalctl / dmesg	OOM Killer 殺了某個 process	檢查被殺的 process 名稱、設定 swap 或 systemd-oomd
`GPU has fallen off the bus`	dmesg	NVIDIA GPU 完全失聯	檢查 PCIe 供電、更新 driver、檢查硬體
`Xid ... pid=`	dmesg	NVIDIA GPU 錯誤（Xid 編號對應不同類型的錯誤）	查 NVIDIA 的 Xid 錯誤代碼表
`GPU reset begin`	dmesg	AMD GPU driver 嘗試 reset GPU	通常會自動恢復，頻繁出現代表 driver 或硬體問題
`segfault at`	journalctl	某個 process segfault（記憶體存取違規）	記下 process 名稱，搜尋該軟體的已知 bug
`Failed to start`	systemctl status	systemd unit 啟動失敗	看完整的 status 輸出和 journalctl log 找原因
`config error` / `parse error`	各工具自身的 log	Config 檔語法錯誤	檢查最近改過的 config 檔

排查流程

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

判斷影響範圍：只有一個視窗壞了、某個工具壞了、整個桌面壞了、還是系統完全不回應？影響範圍決定要看哪一層的 log。
看 journalctl：journalctl -b -p err 先看本次開機有沒有錯誤等級的訊息。大部分 userspace 的問題（compositor crash、工具 crash）會出現在這裡。
看 dmesg：如果 journalctl 沒有明顯線索、或症狀跟硬體有關（畫面凍結、USB 不回應），dmesg -T --level=err,warn 看 kernel 層有沒有硬體或 driver 錯誤。
查特定工具的狀態：systemctl --user status 或 pgrep 確認工具是否還活著。如果死了，看它最後的 log 訊息。
即時監控：如果問題是漸進式的（越來越慢、偶爾卡頓），開 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 插槽接觸、供電、溫度）。

Journalctl on Tarragon