科技 · 實用指南
journalctl 清理釋放 0B？先輪替活動日誌並解釋容量下限
區分活動與封存日誌，按持久或揮發性儲存選擇上限，並驗證總量為何仍可能高於目標。
journalctl 清理成功執行後，仍可能釋放 0B，或者讓磁碟用量高於指定目標；這不一定表示命令失效。顯示的用量包含活動日誌檔案與封存日誌檔案，而 vacuum 只刪除封存檔案。如果這次清理需要涵蓋目前為止寫入的資料，應先輪替日誌。
一次性清理與限制往後的儲存用量是兩件事。/var/log/journal 下的持久日誌使用 System 設定，/run/log/journal 下的揮發性日誌使用 Runtime 設定。即使上限設定正確，活動日誌檔案與檔案大小粒度仍可能使總用量高於名義目標。
1. 刪除前記錄基準
執行 sudo journalctl --disk-usage 並記錄輸出。接著檢查 sudo du -sh /var/log/journal /run/log/journal 2>/dev/null 和 sudo journalctl --list-boots。第一條命令提供 journal 自身統計的用量；目錄檢查則有助於確認相關儲存是持久、揮發性，還是兩者都有。不要只憑發行版名稱推斷儲存類型。
清理前，先保存事故調查、稽核或支援請求需要的日誌。本流程管理本機 journal 儲存，不涵蓋 journal-remote 的保留原則、匯出的封存，或複製到正在使用的 journal 目錄階層之外的檔案。
2. 修改設定前，先解釋 0B 的結果
上游手冊說明，--disk-usage 包含活動與封存檔案，而 vacuum 只處理封存檔案。如果儲存中只有活動檔案，即使設定很小的目標，也可能釋放 0B。Server Fault 的案例正是如此：後來有了封存檔案，清理才釋放空間。
不要把 --vacuum-size=0 當成清空捷徑。目前 systemd 文件規定，0 表示不啟用這項限制條件。應選擇非零目標，並為系統保留足夠的診斷歷史。
3. 執行範圍明確的一次性清理
若要讓清理涵蓋目前為止寫入的資料，執行 sudo journalctl --rotate --vacuum-size=500M，並把 500M 換成你評估後的目標。組合使用這兩個選項，會先輪替活動檔案，再清理封存檔案。不要在 journald 使用 .journal 檔案期間手動刪除它們。
再次執行 sudo journalctl --disk-usage，同時記錄釋放位元組數與新的總用量。仍有占用不代表必然失敗：新建的活動檔案會保留，其他命名空間或儲存也可能貢獻用量。
4. 選擇與儲存類型對應的長期限制
對於 /var/log/journal 下的持久儲存，在本機 journald.conf 的 drop-in 設定片段中設定 SystemMaxUse；如果需要更細的刪除粒度，再設定 SystemMaxFileSize。對於 /run/log/journal 下的揮發性儲存，應改用 RuntimeMaxUse 與 RuntimeMaxFileSize。SystemKeepFree 與 RuntimeKeepFree 為其他用途保留可用空間；journald 會採用適用限制中較小的那個。
Red Hat 將啟用持久日誌作為獨立程序，並透過確認 /var/log/journal 目錄存在且包含檔案來驗證。對於採用 Storage=auto 的系統，這個目錄是否存在會影響儲存方式。請遵循所用發行版的設定機制與驗證工具，不要直接照抄僅適用於某個系統角色的範例。
5. 套用設定並驗證
新增本機 drop-in 設定片段後，用發行版提供的工具核對最終生效的設定，按其支援程序重新載入或重新啟動 systemd-journald，並確認實際使用的儲存目錄。隨後讓系統產生一般日誌，視需要等待輪替，再檢查磁碟用量。設定檔語法正確，仍可能針對了錯誤的儲存類型。
驗證穩定狀態，而不只是查看剛完成清理時的結果。記錄活動檔案大小、封存檔案總量、設定的 MaxUse 與 MaxFileSize，以及剩餘可用空間。這有助於區分真正的持續增長，與文件已說明的活動檔案下限或較粗的檔案大小粒度。
6. 明確結果能夠證明什麼
一次輪替加清理的結果，只能證明符合條件的本機封存日誌檔案已被納入所選條件的檢查。它不能證明所有應用程式日誌都由 journald 儲存，不能證明遠端封存已清理，也不能證明已設定往後的容量上限。
如果用量仍持續超出預期的穩定範圍，應收集實際目錄、活動與封存檔案大小、journal 命名空間、最終生效的設定和 systemd 版本。在證據確定哪個元件消耗空間前，不要反覆降低清理目標。
