Bug 97078

Summary:	starting of syslogd at boot time involves race condition.
Product:	[Retired] Red Hat Linux	Reporter:	Carlo Wood <bugzilla>
Component:	sysklogd	Assignee:	Jason Vas Dias <jvdias>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	9
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-08-18 18:10:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
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 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.