用 journalctl 搵出伺服器「死因」：三個實戰指令救你部 Linux 機

做 IT 嘅朋友，最驚嘅時刻一定係凌晨三點部 production server 突然出事，然後老細打嚟問「點解會 down」。你 SSH 入去，望住個螢幕一片空白，腦入面諗嘅第一件事就係：到底發生咗咩事？

好多時答案就係喺 systemd journal 入面。今日我哋就嚟拆解 `journalctl` 呢個救命工具，教你用三個實戰指令，喺最短時間內搵出系統嘅「死因」。

第一步：睇今次開機之後發生咩事

最常見嘅情況係 server 突然 reboot，你想知 reboot 前最後一刻有咩異常。與其慢慢碌幾千行 log，不如直接睇「今次 boot」嘅 log：

journalctl -b

`-b` 代表「current boot」，只會顯示今次開機之後嘅所有日誌。如果你想睇「上一次」開機（即係 crash 之前嗰次），就加個 `-1`：

journalctl -b -1

呢個指令好有用，因為當系統 crash 咗之後重新開機，上一次 boot 嘅 log 通常仲喺度（只要無開 persistent journal 都係放喺 /run，reboot 會清，但 systemd 通常會保留一定數量）。

第二步：搵出致命錯誤

當你睇緊 log，會發現大量「無聊」訊息，點樣快速篩走雜音？用 priority filter：

journalctl -b -p err

`-p err` 代表只顯示 priority 係 `err`（錯誤）或以上嘅訊息。成個 priority 順序係：

emerg (0)  ← 系統掛咗
alert (1)
crit  (2)
err   (3)  ← 呢個開始值得睇
warning (4)
notice (5)
info  (6)
debug (7)

如果你想睇「warning 或以上」，就係 `-p warning`。實戰上，搵死因通常由 `err` 開始，搵唔到再慢慢放寬到 `warning`。

第三步：追蹤特定服務

假設你已經知道係邊個服務出事（例如 nginx 或者 database），直接追住佢：

journalctl -u nginx.service -b

加個 `–since` 同 `–until` 仲可以鎖定時間範圍：

journalctl -u nginx.service --since "2026-10-20 23:00" --until "2026-10-21 01:00"

進階技巧：實時追蹤 + 關鍵字

如果你想「現場」睇住 log 流動，加 `-f`（follow）：

journalctl -f -u sshd.service

想搵特定關鍵字，用 `grep` 或者內建嘅 `–grep`：

journalctl -b --grep="OOM"

呢個 `–grep=”OOM”` 好有用，因為好多「無故 down 機」嘅元兇其實係 Out Of Memory killer 殺咗個 process。你搵到 `oom-killer` 字眼，就知道係記憶體不足問題，而唔係硬件故障。

小貼士：設定 log 保存量

最後提一提，如果想保住歷史 log（方便事後調查），要開 persistent journal：

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

咁樣 log 就會永久保存喺 /var/log/journal，reboot 都唔會消失。

總結

記住呢三個指令，下次 server 出事你唔使再驚：

1. `journalctl -b -1` — 睇上一次 boot 嘅 log
2. `journalctl -b -p err` — 篩走雜音，只睇錯誤
3. `journalctl -u 服務名 -b` — 追蹤特定服務

🔗 參考資料：NVD NIST 漏洞資料庫

log 唔會講大話，佢只係需要一個識得點樣問佢嘅人。你識得用 journalctl，就係識得問啱問題。

#SSH #ssh #Linux #server #IT教學