Package: syslog-ng
Version: 2.0.9-4.1
Severity: important
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.d/syslog-ng contains "/usr/sbin/invoke-rc.d
syslog-ng reload >/dev/null" as postrotate script in the last block.
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.d/HOSTS") and the new
files begin at 2009-04-13 06:xx (when syslog-ng gets reloaded due to the
logrotate cronjob).
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
Upstream (Balazs Scheidler) confirmed this by email:
your analysis seems to be correct, there's a race between log rotation
and the processing of the SIGHUP signal.
This has been reported initially in Ubuntu:
https://launchpad.net/bugs/361204
-- System Information:
*snipped*, since this is not the system/distribution where the problem occurred.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
