Bug 7214

If you strace the supposedly running syslogd process,
what is it doing?

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.

Works fine here on 5.2 Alpha. Did you restart syslogd & klogd
after installing?

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.

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.

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?

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.

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.

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.

*** Bug 8630 has been marked as a duplicate of this bug. ***

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.

fixed in the glibc package in the current tree