Your message dated Wed, 30 May 2007 20:15:19 +0100
with message-id <[EMAIL PROTECTED]>
and subject line syslogd mysteriously stops logging to tty8
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
Martin Schulze writes ("Re: syslogd mysteriously stops logging to tty8"):
> Martin Schulze wrote:
> > Is this still the case? We've found a bug that caused syslogd to
> > write into wrong files under some race conditions. This was fixed in
> > 1.3-18 and I suppose this also solves your problem. Could you close
> > the bug if you agree?
I haven't seen these symptoms for some time now so I think that must
have been the problem.
> there have been many improvements and bugfixes to syslogd since then.
> Do you mind trying the current CVS version and see if the bug still
> exists? If not, checking the current version in etch may be helpful
> as well.
Sorry for failing to respond earlier, but since I don't have a setup
which reproduces the bug now, and your bug description sounds like the
fault I had, I'm closing the bug.
Ian.
--- End Message ---
