Red Hat Bugzilla – Bug 218227
minilogd assumes /dev/log to be DGRAM
Last modified: 2014-03-16 23:04:29 EDT
Description of problem:
minilogd is designed such that once a full fledged syslog daemon comes up,
minilogd will connect to the socket at /dev/log and forward the logs it
collected so far to the syslog daemon. The problem is that when connecting to
it, minilogd assumes that /dev/log is a datagram socket, instead of using the
more robust code in syslog.c. Syslog.c's code will first try datagram, and if
the 'connect' call fails with errno EPROTOTYPE it will try connecting in stream
This design works with syslogd, but doesn't work with the default syslog-ng
Unfortunately the documentation and sample configurations that come with
syslog-ng claim that /dev/log should be set up as a stream socket (apparently
this was the syslogd default too, up until 1999 when it got changed due to
dubious security concerns). If /dev/log is configured for stream mode, minilogd
fails to forward the logs collected while running rc.sysinit, and all of these
logs are lost.
Also, quite surprisingly, when minilogd initially opens a listening socket at
/dev/log it does so in stream mode. So when the switchover from minilogd to
syslogd occurs, any syslog clients would need to change from stream mode to
socket mode. I don't think it's fair to assume that all applications are capable
of switching from stream mode to dgram mode on the fly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install syslog-ng with default configuration.
2. Enable the syslog-ng daemon and disable syslogd
4. Look for sysctl or fsck output in /var/log/messages
Messages are missing from /var/log
Messages should be present in /var/log
IMO, apps should use glibc, which does handle the transition of socket types, at
least in the testing I did.
Yeah, I guess most apps will do fine. My point was only that if minilogd gets
improved, the system can be set up in a way so that even these theoretical
misguided apps would work correctly. But that's more of a bonus. The real reason
to fix this bug is to ensure that the boot logs don't get quietly lost
regardless of what syslog daemon/configuration people choose to use.
Apologies for the extreme delay. At this point in RHEL 4's lifecycle, we're unlikely to make this change there. Given that minilogd is deprecated, and RHEL 6 will be using a different boot logging mechanism, it's unlikley to change for RHEL 5 as well. Therefore, closing this.