syslog-ng's logrotate config should use delaycompress (loses messages)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
syslog-ng (Debian) |
Fix Released
|
Unknown
|
|||
syslog-ng (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Binary package hint: syslog-ng
I've just noticed that when using logrotate for files handled by syslog-ng (containing messages received from remote syslog-ng instances), that messages are lost, if syslog-ng is not being reloaded after the logfiles got compressed.
I've been using the following in a own file in /etc/logrotate.d:
/var/log/HOSTS/* {
weekly
rotate 7
compress
notifempty
missingok
}
The shipped /etc/logrotate.
It appears that all messages that are targeted at auth.log (the first block) will get discarded while the other blocks get processed, until syslog-ng gets reloaded.
Therefore I think that the "delaycompress" option should get used, so that messages after rotation, but before the reload of syslog-ng will get written to the foo.log.1 file.
I've not verified this (e.g. by testing it explicitly or looking at the source), but the compressed log files last entries are from 2009-04-12 22:xx (where I've manually executed "logrotate /etc/logrotate.
Oddly, there's one logfile, where entries have been written in the meantime (although only "<syslog.info> mydb -- MARK --" - it's a MySQL container which is usually "silent").
I'm not sure if I have manually reloaded syslog-ng (after the manual run of logrotate), but according to the logs I have not.
The OpenVZ hardware node runs Hardy, as do the containers/guests.
logrotate 3.7.1-3ubuntu0.8.04
syslog-ng 2.0.9-1ubuntu1
Changed in syslog-ng (Debian): | |
status: | Unknown → New |
summary: |
- syslog-ng's logrotate config should use delaycompress (lost messages) + syslog-ng's logrotate config should use delaycompress (loses messages) |
Changed in syslog-ng (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in syslog-ng (Debian): | |
status: | New → Fix Released |
Raising importance to High (loss of messages/ information) .
I've asked Balazs Scheidler (upstream) about it and he replied:
your analysis seems to be correct, there's a race between log rotation
and the processing of the SIGHUP signal.
I'll forward this to Debian.