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. > [EMAIL PROTECTED]:/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
