带有logrotate的rsyslog：重新加载rsyslog与copytruncate

我正在使用默认的rsyslog和logrotate实用程序在Ubuntu 14上工作。

在默认的rsyslog logrotate /etc/logrotate.d/rsyslog配置中，我看到以下内容：

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

据我了解，建议在所有logrotate方案中使用copytruncate，因为它不会移动当前日志，而是会截断日志，因此任何使用打开文件处理程序的进程都可以继续对其进行写入。

那么如何使用rsyslog重载功能代替默认配置呢？

要回答您的问题，您首先需要了解重新加载和复制截断的不同权衡：

• reload：旧的日志文件被重命名，写入该日志的进程被通知（通过U​​nix信号）以重新创建其日志文件。这是最快/开销较低的方法：重命名/移动操作非常快，并且执行时间恒定。而且，这几乎是原子操作：这意味着（几乎）在移动/重新加载期间不会丢失任何日志条目。另一方面，您需要一个能够重新加载和重新打开其日志文件的进程。Rsyslog是一个过程，因此默认的logrotate配置使用reload方法。强烈建议rsyslog上游将此模式与rsyslog一起使用。
• copytruncate：将旧日志文件复制到存档文件中，然后将其截断以“删除”旧日志行。尽管截断操作非常快，但是副本可能会很长（取决于日志文件的大小）。此外，在复制操作（请记住，它可能很慢）和截断之间的时间内，某些日志条目可能会丢失。由于这些原因，对于能够重新加载和重新创建其日志文件的服务，默认情况下不使用copytruncate。另一方面，如果服务器不能够重新加载/重新创建日志文件，那么copytruncate是您最安全的选择。换句话说，它不需要任何服务级别的支持。rsyslog上游项目强烈建议您不要使用此模式。

作为rsyslog作者，copytruncate实际上是一个非常非常非常糟糕的选择。它具有固有的灵活性，几乎可以保证您将丢失日志数据。文件写入的频率越高，丢失的内容就越多。这不仅是最后一行的一部分，而且可能是数百行，具体取决于旋转发生时系统的确切时间和状态。

移动文件并创建新的索引节点（文件）后，rsyslog会跟踪先前的文件并完成处理。因此，在这种情况下，您不会有任何损失。保证（除非卸载文件系统...）。

关于“ reopenOnTruncate”：我个人已经看到reopenOnTruncate在其他方面也很合理，尤其是在NFS等方面。一段时间以前，我完全删除了该功能，但后来又说服了合并类似的功能。由于我真的知道人们在负载非常重的系统上会遇到麻烦，因此它可能永远保持“实验性”。“ copytruncate”根本不是使用日志文件的体面模式。

我目前致力于重构文件（ETA 8.34或8.35）。重构的版本可能能够防止由于API争用而导致的意外重新发送，但也无法防止数据丢失-因为从概念上讲这是不可能的。

这完全取决于进程如何写入日志。
copytruncate只有工作，如果日志消息被附加到文件（例如whatever >> logfile，
而不是当它被重定向输出（例如whatever > logfile）。

从版本8.16开始，rsyslog具有reopenOnTruncate处理复制问题的imfile选项。

特别是对于rsyslog来说，保持原样可能更有意义。

根本原因是rsyslog具有内部队列，可以在其输出句柄不可用的情况下使用。

重新加载将a）使rsyslog重新创建其自己的日志文件，并且b）使所有排队的事件在创建时刷新到该文件。

它可能是copytruncate并没有害处（尽管我会担心部分写入的行会被截断），但是从完整性的角度来看，我倾向于认为复制/删除/重装是“更安全的”。

如@ faker所述，由于rsyslog可以处理其文件不可用的情况，因此没有令人信服的理由使用copytruncate。

就像@ SelivanovPavel提到的那样，rsyslog实际上需要特定的配置才能正确处理副本截断。

因此，如果仅因为使用此reload方法需要与默认配置的偏差较小，我就会保留它。