Bug#3059: No more logs since cron.weekly rotation
Package: syslogd
Version: 1.3-2
Note to anyone that reples to this - check the headers, and don't cc to
debian-bugs if you aren't adding something useful.
> Files in /var/adm as daemon.log, messages, auth.log don't get updated this
> morning. Here's the rest of a ls -ltr in /var/adm
I think I know what the problem is.
> -rw-r--r-- 1 root adm 0 May 19 06:47 messages
> -rw-r--r-- 1 root adm 0 May 19 06:47 messages.0
Notice that all the logfiles have their first rotation, ie foo.0,
empty.
I also observe on my system that syslogd is logging to the first
rotation, not to the original. It still has the fd open to the first
rotation.
> edd@miles:/var/adm> w
> 9:27am up 11 days, 14:59, 1 user, load average: 0.08, 0.05, 0.01
Your uptime is over one week. syslogd, in your case, still has the fd
open to the second rotation, foo.1.gz. You can use strace to see if
the writes to those files are succeeding (and corrupting them), or
failing, which is was I suspect.
After you strace syslogd, SIGHUP it, and I'll bet you'll get logging
again.
The bug is in syslogd - the last line of the /etc/cron.weekly/sysklogd
script reads "/etc/init.d/sysklogd reload". Presumably this
UNDOCUMENTED reload command has the same effect as sending a SIGHUP to
syslogd. Except it doesn't.
Further proof:
Examing the files in /proc/64/fd/ convinces me that syslogd really
does still have the old files open. It's logging to the foo.0 files on
my system. 64 is syslogd's pid on my system.
After I SIGHUP syslogd, everything works again. I see another bug in
syslogd - that it didn't close the fd's for the old log files. If I
send syslogd 1024/8 SIGHUPS, or if syslogd is up for that many weeks,
logging will totally stop. Only 1024 open fd's allowed per process.
The easiest fix to the more important bug is just to change the last
line of /etc/cron.weekly/sysklogd to
kill -SIGHUP $(cat /var/run/syslog.pid)
Guy
Reply to: