Bug 7214 - logs stop after upgrade to sysklogd-1.3.31-1.5
Summary: logs stop after upgrade to sysklogd-1.3.31-1.5
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
: 8630 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-22 01:13 UTC by michael
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-05 02:29:25 UTC

Attachments (Terms of Use)

Description michael 1999-11-22 01:13:50 UTC
The problem is showing up on my Redhat Linux 5.2 machine.  I have not seen
this problem on my Redhat 6.0 box.

After installing the latest update of sysklogd, no information is being
recorded in /var/log/messages, ./maillog or ./secure   After reverting to
sysklogd-1.3-25, the logs start working again.  When sysklogd-1.3.31-1.5
was installed, I tried restarting /etc/rc.d/init.d/syslog, but it gave an
error that the PID (number) that the daemons were running under was no
longer valid.  However, before attempting to restart the daemon, a ps -ef
showed that both syslogd and klogd were "supposedly" running.  Normally, if
the logger is working correctly, there will be several lines added to the
/var/log/messages file to show the startup, however these informational
lines do not show up when the updated klogd and syslogd are installed and
started.  It appears that the daemons are failing "half way" and appear
started when they are not actually running.

Comment 1 Bill Nottingham 1999-11-22 15:52:59 UTC
If you strace the supposedly running syslogd process,
what is it doing?

Comment 2 furiorh 1999-12-15 21:23:59 UTC
I am also observing the same thing on Alpha Linux RH 5.2.
It was with sysklogd-1.3.31-0.5.alpha.rpm and it
stopped working with  sysklogd-1.3.31-1.5.alpha.rpm.
Almost! In the sense that I get *very few* lines in the
log from time to time.

This is the only additional information that I can give.
My machines are production servers and cannot afford to do any
further testing because I really need the logs.  I am now going
back quickly to sysklogd-1.3.31-0.5.alpha.rpm.

Comment 3 Bill Nottingham 1999-12-15 23:42:59 UTC
Works fine here on 5.2 Alpha. Did you restart syslogd & klogd
after installing?

Comment 4 Bill Nottingham 1999-12-16 17:03:59 UTC
Also, are you using any software that is not logging through
the standard glibc syslog() calls?  If so, it's possible
that that software could break, and therefore it needs to
be fixed to work with the new syslogd.

Comment 5 furiorh 2000-01-16 00:04:59 UTC
Sorry for the delayed answer.

Question 12/15/99 18:42: yes I did ( /etc/rc.d/init.d/syslog stop
	and /etc/rc.d/init.d/syslog start ).

Question 12/16/99 12:03: during the four hours I had sysklogd-1.3.31-1.5
	on four servers I lost logging from at least the following products:
	Merit Radius 3.6B (totally), sshd from ssh 1.2.27 (totally),
	sendmail 8.9.1 (almost totally), BIND 8.2.2_P3 (totally)
	On the other hand, logging from Qualcomm qpopper 2.51 seems to have
	gone unaffected, and also logging from postfix.
	Of all these products, BIND was the only one directly taken from
	a RH rpm (bind-8.2.2_P3-0.5.2), so perhaps you can concentrate on
	that one for debugging. In named.conf I have

	logging {
        	channel spin_syslog {
        	        syslog local2;
        	        severity info;
        	category default { spin_syslog; default_debug; };

	and in syslog.conf:

	*.info;mail,local0,local1,local2,authpriv.none  /var/log/messages
	local2.*                            -/var/log/namedlog

	Note that '-' to suppress file syncing; however I use that also
	for qpopper and postfix logs, which went on working.

Comment 6 Bill Nottingham 2000-01-21 06:21:59 UTC
Did you have bind running in a chroot()? If bind is running chrooted,
it sometimes runs a process in the chroot() to handle logs, and this
could be using the wrong protocol.

Were any of the other three programs libc5-based?

Comment 7 furiorh 2000-01-21 15:48:59 UTC
My bind is not running chrooted.

What is the criterion to see if a program is "libc5-based"
or "libc6-based"? I looked into some source codes and did not
find this information in obvious places.  qpopper, postfix,
Merit Radius sources barely mention Linux at all.
If you can give me a hint on what to look for, I may try to
supply more information.

Comment 8 Bill Nottingham 2000-01-21 22:05:59 UTC
Run 'ldd' on the binaries; if it says:

	libc.so.6 => /lib/libc.so.6

it's libc6 (aka glibc), if it says:

	libc.so.5 => <somewhere>/libc.so.5

it's libc5.

Comment 9 furiorh 2000-01-22 00:52:59 UTC
Thanks for the tip.  For all the programs mentioned above I found
	libc.so.6.1 => /lib/libc.so.6.1
I do not even have a libc.so.5 in my systems.

Comment 10 Bill Nottingham 2000-02-01 19:37:59 UTC
*** Bug 8630 has been marked as a duplicate of this bug. ***

Comment 11 Bill Nottingham 2000-02-01 20:11:59 UTC
OK, the problem here is in glibc's syslog.

syslog() tries first datagram sockets, and then stream sockets.
If it ends up having to use stream sockets, it then will not
fall back to datagram sockets later on in that program run,
even if you do an explicit closelog().

Hence, programs that run into this will need restarted,
such as sshd. :(

Programs that do their own openlog(), etc. in forked
subprocesses (such as qpopper, I'm assuming), would work
unaffected. The fix for this would lie in glibc.

Comment 12 Cristian Gafton 2000-02-05 02:29:59 UTC
fixed in the glibc package in the current tree

Note You need to log in before you can comment on or make changes to this bug.