使用 newsyslog 輪換後，rsync 輸出（正在進行）未記錄在新日誌文件中

我今天早上發現，在由 newsyslog 輪換後，正在進行的 rsync 輸出不會出現在 rsync 日誌中。它失去了

換句話說，

• 正在執行的 rsync 正在記錄到 /var/log/rsync
• newsyslog 進行日誌輪換
• 新的 /var/log/rsync 中沒有輸出。
• 輸出沒有在我能看到的任何地方擷取。

我究竟做錯了什麼？

這是 rsync 命令（從執行 cygwin 的 Windows 機器上的 rsyncd 模組中提取）。它是 rsnapshot 命令的一部分，但這與此問題無關。

/usr/local/bin/rsync -av --delete --relative --delete-excluded --stats --log-file=/var/log/rsync --human-readable --no-owner --no-group --exclude-from=/yada/yada/.rsnapshot_excludes 192.168.3.130::INC-10890_data/ /zfspoolname/archives/daily.0/LOCATIONSIGNIFIER/INC-10890_data/

這是 /var/log/rsync.0 的最後 5 行（解壓縮後）。

[root@offsite1 ~]# tail -5 /var/log/rsync.0
2019/02/11 01:03:54 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_102.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_103.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_104.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_105.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_106.bmp

這是 /var/log/rsync 中的內容：

> [root@offsite1 ~]# tail -5 /var/log/rsync   Feb 11 01:00:00 offsite1
> newsyslog[61988]: logfile turned over

這是今天早上我終止 rsync 作業時螢幕上的最後幾行內容（我讓命令 tail -f /var/log/rsync 執行了一夜）。這應該顯示在 /var/log/rsync 中，因為我在它上面執行了一個 tail -f。當不涉及 newsyslog 時，我有這種類型的輸出出現在 /var/log/rsync 中的經驗。

> 2019/02/11 07:13:52 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_027.bmp
> 2019/02/11 07:13:52 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_028.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_029.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_030.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_031.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_032.bmp
> 2019/02/11 07:13:54 [12868] rsync error: received SIGINT, SIGTERM, or
> SIGHUP (code 20) at rsync.c(689) [generator=3.1.3] 2019/02/11 07:13:54
> [20023] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at
> io.c(504) [receiver=3.1.3]

這是 /usr/local/etc/newsyslog.conf.d/rsync 中的內容

#
# The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/rsync                          644  13    *    $W1D01 JCN

最後

[root@offsite1 ~]# uname -a
FreeBSD offsite1.domanname.com 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC  amd64

newsyslog會將日誌文件移動到一個新名稱 ( /var/log/rsync.0) 並壓縮它（到/var/log/rsync.0.bz2，由於J您在 中使用的標誌newsyslog.conf）。然後它使用舊名稱（中的C標誌newsyslog.conf）創建一個新文件。

這意味著寫入該文件的程序將寫入一個不再存在的文件（嗯，它確實存在，但沒有名稱）。對應的inode/var/log/rsync將不再有名稱，並且一旦rsync關閉文件句柄，文件使用的空間將被回收。壓縮文件時，inode 失去了它的名稱。

通常，系統服務會發送HUP信號newsyslog，通常這意味著它們將重新打開其日誌文件以進行寫入。這意味著他們將開始寫入新清除的日誌文件，而不是寫入 void。

rsync據我所知，沒有該設施，因此在日誌文件旋轉點之後寫入的所有內容都將失去。

根據創建備份文件的方式，如果您只是禁用旋轉日誌的壓縮rsync.0，您可能會rsync繼續寫入該文件。

您可以通過使用 的p標誌列中的標誌來執行此操作newsyslog.conf，這將使第零個旋轉日誌文件保持未壓縮但壓縮較舊的日誌文件。見newsyslog.conf(8)。

請注意，如果同一程序在第二個日誌文件輪換rsync期間保持活動狀態，則僅禁用第一個日誌的壓縮仍會導致問題，因為該文件將被重命名為然後壓縮為（這又是同樣的問題）。完全禁用日誌文件壓縮會解決這個問題。rsync.0``rsync.1``rsync.1.bz2

引用自：https://unix.stackexchange.com/questions/500014