☰

使用 newsyslog 轮换后，rsync 输出（正在进行）未记录在新日志文件中

tag-icon • tag-icon freebsd rsync
使用 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

答案1

newsyslog会将日志文件移动到新名称 ( /var/log/rsync.0) 并将其压缩（/var/log/rsync.0.bz2由于J您在 中使用了标志，因此压缩为newsyslog.conf）。然后它使用旧名称（C中的标志newsyslog.conf）创建一个新文件。

这意味着写入该文件的进程将写入一个不再存在的文件（嗯，它确实存在，但没有名称）。一旦关闭文件句柄，对应的索引节点/var/log/rsync将不再有名称，并且文件使用的空间将被回收。rsync当文件被压缩时，inode 就失去了它的名字。

HUP通常，系统服务通过发送信号newsyslog，通常这意味着它们将重新开放他们的写作日志文件。这意味着他们将开始写入新清除的日志文件，而不是写入空白。

rsync据我所知，没有这种设施，因此在日志文件轮换点之后写入的所有内容都将丢失。

根据备份rsync.0文件的创建方式，您可能会rsync继续写入那如果您只是禁用轮换日志的压缩，则可以使用该文件。

您可以通过使用 的p标志列中的标志来执行此操作newsyslog.conf，这将使第零个轮换日志文件保持未压缩状态，但会压缩较旧的日志文件。看newsyslog.conf(8)。

请注意，如果同一rsync进程在整个过程中保持活动状态，则仅禁用第一个日志的压缩仍然会导致问题。第二日志文件轮换，因为rsync.0文件将被重命名为rsync.1然后压缩为rsync.1.bz2（这是同样的问题）。禁用日志文件压缩完全地会解决这个问题的。

相关内容