Bug 97078 - starting of syslogd at boot time involves race condition.
Summary: starting of syslogd at boot time involves race condition.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sysklogd   
(Show other bugs)
Version: 9
Hardware: All Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-06-10 01:11 UTC by Carlo Wood
Modified: 2007-04-18 16:54 UTC (History)
0 users

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

Attachments (Terms of Use)

Description Carlo Wood 2003-06-10 01:11:26 UTC
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:

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 21:26:36 UTC
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 10:21:41 UTC
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 18:09:33 UTC
 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.