Bug 218227 - minilogd assumes /dev/log to be DGRAM
minilogd assumes /dev/log to be DGRAM
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: initscripts (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-03 17:03 EST by Tamas Kerecsen
Modified: 2014-03-16 23:04 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-08 16:52:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tamas Kerecsen 2006-12-03 17:03:40 EST
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
Comment 1 Bill Nottingham 2006-12-04 13:26:42 EST
IMO, apps should use glibc, which does handle the transition of socket types, at
least in the testing I did.
Comment 2 Tamas Kerecsen 2006-12-05 21:32:31 EST
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.
Comment 3 Bill Nottingham 2008-12-08 16:52:29 EST
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.

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