Upstart 不會在 logrotation 上重新開啟日誌文件

Upstart 不會在 logrotation 上重新開啟日誌文件

我們使用 upstart 來管理 Ubuntu 伺服器上的服務。它們產生的日誌會登出到 /var/log/upstart/SERVICE_NAME.log

然後每天使用 12.04 LTS 附帶的 logrotation 腳本輪換日誌檔:

/var/log/upstart/*.log {
        daily
        missingok
        rotate 7
        compress
        notifempty
        nocreate
}

問題是,當 logrotate 移動檔案時,它似乎沒有向 upstart 發出關閉並重新開啟檔案的訊號,從而使 upstart 進程寫入刪除 PID。

init          1       root    8w      REG              202,1        64       2431 /var/log/upstart/dbus.log.1 (deleted)
init          1       root   13w      REG              202,1        95       2507 /var/log/upstart/acpid.log.1 (deleted)
init          1       root   14w      REG              202,1       127      17377 /var/log/upstart/whoopsie.log.1 (deleted)
init          1       root   36w      REG              202,1       122       6747 /var/log/upstart/SERVICE_NAME.log.1 (deleted)
init          1       root   37w      REG              202,1        30       6762 

顯然,我可以將輸出從我自己的服務重定向到其他日誌文件,但係統進程仍然存在問題。另外,我寧願不必建造比我需要的更多的基礎設施。

答案1

我相信你有3個選擇。

  1. 您透過新增“copytruncate”來修改現有配置

    /var/log/upstart/*.log { copytruncate daily missingok rotate 7 compress notifempty nocreate }

  2. 如果您無法或(不允許)更改現有的 logrotate 配置,因為其他日誌檔案不會受到影響且現有配置適用於它們,則將您的「SERVICE_NAME.log」檔案移至 / 下的新資料夾var /log 如果您願意,可以使用「copytruncate」建立一個新配置並將其新增至cron.daily。

  3. a) 如果您不允許更改主機作業系統 logrotate 設定或新增至主機作業系統的 cron.daily,那麼您的第三個選擇是更改腳本或程式以在寫入檔案之前檢查檔案是否存在。 b) 另一種方法是上面第 2 點的一點,即將日誌檔案移動到其他位置並在腳本或程式中執行特定於該程式日誌檔案的 logrotate 命令。

上面的第 3b 點更棘手,但更優雅,這是我大部分時間使用的,因為它意味著程式是自給自足和自我管理的,不需要作業系統的工作來照顧它。

要了解如何手動執行 logrotate 並將其新增至您的程式或腳本中,只需鍵入:

man logrotate

或者

logrotate --help

如果您的程式使用 Python,您可以查看該程式如何使用它來自我管理其日誌檔案。 http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

答案2

事實證明,這是已知問題當我輸入此內容時保持開啟。

正確的做法可能是完全刪除所有服務/etc/logrotate.d/upstart並分別輪換各個服務的檔案。因為目錄 ( /var/log/upstart/) 只包含各種服務的 stdout/stderr -且不包含任何要作為服務運行的服務。守護程式應該輸出到這兩個通道。也許除了在剛開始的時候。

在我管理的系統上,有三個服務由 upstart 執行:php5.6-fpmphp7.1-fpmacpid。三個日誌都不是活動的,但有時 fpm 由於其主日誌檔案 ( /var/log/php5.6-fpm.log) 被輪換而重新啟動——這會導致這種噪音,因為它在啟動時輸出一些空洞的訊息。

如果您堅持要輪換這些文件,您可以相信它們的名稱與服務名稱匹配並使用以下postrotate腳本:

    postrotate
            service=${1##*/}
            service=${service%.log*}
            service $service restart > /dev/null
    endscript

為了使上述工作正常進行,請務必不是使用sharedscripts那裡的動詞——我的腳本依賴於這樣一個事實,文件的實際路徑將作為第一個參數傳遞給它($1)。

(重定向到/dev/null很有用,因為service-command 很吵——而且你不希望 cron 透過電子郵件將這樣的噪音發送給你。注意,我不會重定向到stderr那裡,只是stdout——如果出現問題,你我仍然會收到您的電子郵件。

相關內容