rsyslog与logrotate：重新加载rsyslog vs copytruncate

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

在默认的rsyslog logrotate /etc/logrotate.d/rsyslogconfiguration我看到以下内容：

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

据我所知，build议在所有logrotatescheme中使用copytruncate，因为它不会移动当前日志，而是截断日志，所以任何具有打开文件处理程序的进程都可以继续写入日志。

那么为什么使用rsyslog重载function的默认configuration呢？

要回答你的问题，你需要了解重载和copytruncate的不同权衡：

重新加载 ：旧的日志文件被重命名，并通知（通过Unix信号）写入该日志的进程重新创build其日志文件。这是最快的/较低的开销方法：重命名/移动操作非常快，并具有恒定的执行时间。而且，这几乎是primefaces操作：这意味着在移动/重装过程中（几乎）没有日志条目会丢失。另一方面，您需要一个能够重新加载和重新打开其日志文件的进程。 Rsyslog是这样一个过程，所以默认的logrotateconfiguration使用重载方法。
copytruncate ：将旧的日志文件复制到一个存档文件中，然后将其截断为“删除”旧的日志行。虽然截断操作非常快，但副本可能很长（取决于日志文件的大小）。而且，在复制操作（记住，它可能很慢）和截断之间的时间内，某些日志条目可能会丢失。由于这些原因，对于能够重新加载并重新创build其日志文件的服务，缺省情况下不使用copytruncate。另一方面，如果服务器无法重新加载/重新创build日志文件，copytruncate是最安全的select。换句话说，它不需要任何服务级别的支持。

这完全取决于进程如何写日志。
如果日志消息被追加到文件（例如， whatever >> logfile文件）， copytruncate只能起作用。
而不是当它redirect输出（例如whatever > logfile ）。

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

对于rsyslog而言，将事情保持原样可能更有意义。

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

重新加载将a）导致rsyslog重新创build自己的日志文件，以及b）在创build时导致任何排队的事件被刷新到文件。

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

正如@ faker所提到的，由于rsyslog可以处理文件变得不可用的情况，所以没有令人信服的理由来使用copytruncate。

正如@ SelivanovPavel所提到的，rsyslog实际上需要特定的configuration才能正确地处理复制截断。

所以，如果只是因为使用reload方法需要较less的偏离默认configuration，我会保持它。