什么时候在logrotate中使用delaycompress选项?

logrotate的手册页说:

 It can be used when some program cannot be told to close its logfile and thus might continue writing to the previous log file for some time. 

我很困惑。 如果一个程序不能被告知closures它的日志文件,它将会一直写下去 ,而不是一段时间 。 如果压缩被推迟到下一个旋转周期,即使在下一个旋转周期之后,程序也继续写入该文件。 如何推迟解决问题?

我的理解是,当程序不能被告知closures日志文件时,应该使用copytruncate 。 我知道写入日志文件的一些数据在复制过程中会丢失。

我正在查看couchdb的logrotate文件,它有copytruncatedelaycompress选项。

 /usr/local/couchdb-1.0.1/var/log/couchdb/*.log { weekly rotate 10 copytruncate delaycompress compress notifempty missingok } 

看起来像是在copytruncate已经存在的时候,使用delaycompress没有意义。 我错过了什么?

你对copytruncate理解是正确的,但是对于delaycompress的措辞有点误导。 更恰当地说,应该说“某些程序不能被告知立即closures它的日志文件” – 例如,如果你正在使用共享脚本,并且脚本在所有的日志文件被旋转时使用日志向进程发送信号。

不知道我是否完全理解你的问题,但如果你问我的想法…我使用这个:

 postrotate killall -HUP syslog-ng endscript 

这是一个很好的(或至less是)杀死日志和移动到下一个的方法。 对于像“思科ASA平台”那样的“程序”来说,它每秒钟都会logging大量的数据。