Bug 97078 - starting of syslogd at boot time involves race condition.
starting of syslogd at boot time involves race condition.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: sysklogd (Show other bugs)
9
All Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-09 21:11 EDT by Carlo Wood
Modified: 2007-04-18 12:54 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-18 14:10:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Carlo Wood 2003-06-09 21:11:26 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):


How reproducible:
Sometimes

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.
    

Additional info:
Comment 1 Jason Vas Dias 2004-08-16 17:26:36 EDT
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 
returns non-zero. 


*** This bug has been marked as a duplicate of 126223 ***
Comment 2 Carlo Wood 2004-08-17 06:21:41 EDT
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.
Comment 3 Jason Vas Dias 2004-08-18 14:09:33 EDT
 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.

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