Bug#2883: syslogd mysteriously stops logging to tty8
Package: syslogd
Version: 1.2-9
My syslog.conf contains:
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
kern.*;user.*;local2.*;auth.*;daemon.*;mail.*;news.crit;
news.err;news.notice;*.=debug;*.=info;*.=notice;*.=warn;cron.none -/dev/tty8
(Line wrap is just in this posting; in fact `news.crit;' and
`news.err' have no spaces in between, and cron.none is followed by a
tab not a space.)
Every night my system goes down for backups; this involves switching
to a runlevel where not many daemons are running, doing the backup,
and then switching back. syslogd is kept running; it is not restarted
on the runlevel changes, because I only have S links for it in all the
runlevels in question.
During the backup I can see that syslog is still working properly, and
logging to tty8 - `logger' can be used to show this, and named
periodically logs some guff which I can see.
However, when the backup is complete the system switches back to a
normal multiuser runlevel. After this runlevel change syslogd has for
some unknown reason decided not to write to tty8 any more. I have to
send it a SIGHUP to get it to start writing there again.
There are no other processes which do anything to tty8, to my
knowledge.
This message is really about two bugs:
(a) The bug that syslogd stops logging to tty8.
(b) The bug that it doesn't appear to provide any way to find out why
it has decided to stop logging on a particular file/device. It ought
to record the system call that it was attempting and the errno value,
perhaps in a file specially opened for the purpose, or by using a
special log message.
I can supply an strace listing of syslogd as it fails, made by
attaching strace to syslogd during the backup and then detaching it
after the system had come back up.
Ian.
Reply to: