網站 access log 沒有輪替？用 logrotate 預演與確認程序重新開檔

網站 access log 持續變大，即使設定了 logrotate 也沒有產生新檔，原因可能是排程沒執行、設定未包含該檔、輪替條件未達，或服務仍寫入舊檔。先確認是否有磁碟空間危機與日誌保留要求；不要直接清空或刪除正在寫入的檔案。

確認路徑、排程與設定

先記錄實際日誌路徑、大小、擁有者、最近修改時間，以及主機使用的 logrotate.timer 或 cron。查看 /etc/logrotate.conf 和包含的設定檔，確認同一日誌沒有被重複定義。系統管理者可執行：

systemctl status logrotate.timer
systemctl list-timers logrotate.timer
sudo logrotate -d /etc/logrotate.conf

排程方式與檔案位置依系統而異。官方文件指出 -d 是除錯預演，不會輪替日誌或更新狀態檔；輸出可能表示不需輪替、設定解析錯誤或無權存取。預演成功不保證正式輪替及服務重開檔一定成功。不要為了測試直接使用 -f 強制輪替正式日誌。

判讀輪替方式

核對 daily、size、rotate 與實際執行頻率；size 設定不代表 logrotate 會持續監看檔案，仍受排程執行頻率影響。若使用 rename 與 create，還需依 Web 伺服器官方程序讓程序重新開啟日誌；若仍寫入已改名檔案，新檔可能保持空白。copytruncate 會先複製再截斷原檔，適用於不能重新開檔的程式，但複製與截斷間可能漏掉少量日誌，不能視為零損失。不要在不了解套件既有 postrotate 的情況下照貼設定。

受控驗證與回復

先備份受管設定並確認保留政策，以測試環境及測試日誌驗證修改；再安排維護時段套用。正式輪替後確認新檔擁有者、權限與時間，發出一個無敏感資訊的網站測試請求，查看該請求是否寫入新日誌，並確認舊檔依政策保存。若服務仍寫入舊檔或權限錯誤，依備份還原設定，按服務官方程序恢復正常寫入；保留現有日誌，勿以清空檔案作為復原。若空間來自 systemd journal，另參考journalctl 容量檢查。

範例：觀察排程與寫入位置

預演輸出若指出 log does not need rotating，應比對條件、上次輪替時間與排程頻率；若顯示設定重複或無法讀取路徑，先處理設定來源或權限。下列命令僅列出範例檔案資訊，請改成已確認的實際路徑：

sudo ls -li /var/log/nginx/access.log*
sudo systemctl status logrotate.timer

輪替後記錄新舊檔案的 inode、大小與時間，透過網站執行一次安全測試請求，再觀察新檔大小或時間是否增加。inode 不同且新檔未增長，可能仍寫入舊檔，但仍需結合程序開啟檔案資訊與服務設定判斷；copytruncate 保留原 inode，因此不能用 inode 是否變更單獨判斷成功。狀態檔的位置與排程依系統設定為準，避免手改狀態檔掩蓋原因。

在測試主機建立獨立測試日誌與設定，先用 logrotate -d 指向該測試設定確認解析，再由管理者評估何時執行實際輪替。正式站應先確認 postrotate 腳本、服務重新開檔程序與權限；執行中若發生日誌寫入中斷，恢復設定後按服務官方程序重新開檔並再次產生測試請求。已輪替或刪除的歷史資料不會因還原設定自動復原，需要依日誌備份與保留政策處理。