Red Hat Bugzilla – Bug 97078
starting of syslogd at boot time involves race condition.
Last modified: 2007-04-18 12:54:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
At boot, from /etc/rc.d/init.d/syslog, syslogd is started
with the line:
daemon syslogd $SYSLOGD_OPTIONS
where SYSLOGD_OPTIONS is set to "-m 0".
However, 'daemon' is defined in 'functions' to call:
$nice initlog $INITLOG_ARGS -c "$*"
where $* is now "syslogd -m 0".
It should be noted that initlog tries to connect
to syslogd and that it is possible that this
returns a failure ($? unequal 0) in some cases and
not in other cases.
I did notice this in particular while running
redhat 9 in user mode (http://user-mode-linux.sourceforge.net/)
which happens to show this problem clearly.
Sometimes the start-up is successful and other times
[FAILURE] is printed (syslogd still starts).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Couldn't really reproduce this on plain RH9, you'll need UML
2.and as far as I know I am the first in the world who got RH9
3.running as UML with kernel 2.5.70... I am not asking you
to try that :/ Using common sense I think there should be
a trivial way to start syslogd from init.d/syslog, NOT using
the 'daemon' function.
Cleaning out old bugs here.
Actually, I think this is a duplicate of bug 126223, which fixes a
race where syslogd parent was thinking the child hadn't started
when it actually had; initlog wouldn't be returning non-zero if
it failed to connect to syslog, only if the process it runs
*** This bug has been marked as a duplicate of 126223 ***
After reading 126223, I have to disgree that this is a duplicate of
that bug. Sure, it contains the words "syslogd" and "race condition",
but there the resemblance stops.
The race condition that I was talking about has to do with the fact
that the 'daemon' script used by RedHat reports to syslogd (by
connecting to it). Therefore, you cannot/shouldnot use 'daemon' to
start syslogd itself.
Now NORMALLY this never fails for some reason - so apparently the race
condition is such that he right process always wins. The race condition
DOES exist however - and it indeed and actually fails to work in UML.
initlog DOES NOT USE syslogd - it uses /sbin/minilogd, to deal with
logging when syslogd has not been started.
The init script which runs syslogd would ONLY display "FAILED"
if the parent process of syslogd returns non-zero; precisely this
was happening in bug 126223, where SOMETIMES on multi-processor
systems the child would send SIGTERM before the parent had installed
the SIGTERM handler, causing the parent to exit non-zero when in fact
the child continues merrily along.
Please try installing sysklogd-1.4.1-22 and see if this fixes your
problem (I'll try to get it built for RH9-updates).
If it does not, then by all means re-open this bug.