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 mode instead. This design works with syslogd, but doesn't work with the default syslog-ng configuration. 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): N/A How reproducible: Steps to Reproduce: 1. Install syslog-ng with default configuration. 2. Enable the syslog-ng daemon and disable syslogd 3. Reboot 4. Look for sysctl or fsck output in /var/log/messages Actual results: Messages are missing from /var/log Expected results: Messages should be present in /var/log Additional info: N/A
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.