Bug 126223 - syslogd not handling -f option properly
syslogd not handling -f option properly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sysklogd (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brian Brock
:
: 123906 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-17 14:56 EDT by Jason Dixon
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-19 20:09:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix syslog (733 bytes, patch)
2004-08-02 14:07 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Jason Dixon 2004-06-17 14:56:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040124 Galeon/1.3.13

Description of problem:
The syslogd in RHEL 3 doesn't appear to be handling the -f option
properly.  We use an alternate location for our syslog.conf, as
defined in /etc/sysconfig/syslog:

SYSLOGD_OPTIONS="-m 0 -f /etc/syslog-digex.conf"

If the original syslog.conf is missing or contains misunderstood
syntax (our is used as a macro for combining various syslog files),
then syslogd will terminate at startup:

[root@uni-dl380-38]~# syslogd -m 0 -f /etc/syslog-digex.conf
Terminated

Interestingly, the service starts anyways:

[root@uni-dl380-38]~# ps ax | grep syslog
 1282 ?        S      0:00 syslogd -m 0 -f /etc/syslog-digex.conf

This behavior is also erratic.  Occassionally, syslogd will startup
without any problems.  For example, when restarting the syslog service:

[root@uni-dl380-38]~# service syslog restart
Shutting down kernel logger:                               [  OK  ]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [FAILED]
Starting kernel logger:                                    [  OK  ]
[root@uni-dl380-38]~# service syslog restart
Shutting down kernel logger:                               [  OK  ]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [FAILED]
Starting kernel logger:                                    [  OK  ]
[root@uni-dl380-38]~# service syslog restart
Shutting down kernel logger:                               [  OK  ]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [FAILED]
Starting kernel logger:                                    [  OK  ]
[root@uni-dl380-38]~# service syslog restart
Shutting down kernel logger:                               [  OK  ]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
Starting kernel logger:                                    [  OK  ]
[root@uni-dl380-38]~# service syslog restart
Shutting down kernel logger:                               [  OK  ]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [FAILED]
Starting kernel logger:                                    [  OK  ]

And yet, you can still see that syslogd has started:

[root@uni-dl380-38]~# ps ax | grep log
 1573 ?        S      0:00 syslogd -m 0 -f /etc/syslog-digex.conf
 1577 ?        S      0:00 klogd -x


Version-Release number of selected component (if applicable):
sysklogd-1.4.1-12.1

How reproducible:
Sometimes

Steps to Reproduce:
1. Remove or replace the default /etc/syslog.conf (with bad syntax)
2. Configure /etc/sysconfig/syslog to use an alternate syslog.conf
with the -f option
3. Start/restart the syslog service
    

Actual Results:  FAILED system logger.

Expected Results:  System logger starts successfully, without any errors.

Additional info:

This configuration works fine in RHEL 2.1.
Comment 1 Neil Horman 2004-08-02 14:07:33 EDT
Created attachment 102368 [details]
patch to fix syslog

The problem appears to be the order in which syslog registers for SIGTERM and
forks.	Currently syslogd forks a child and then registers for SIGTERM, which
the syslog child send to terminate the parent after the child has parsed the
config file.  If the scheduler runs the child first, it is possible that the
child can send the SIGTERM before the parent register to receive it, causing
unknown exit codes to be given.  This patch reverses that order, and resets the
child signal handler for SIGTERM to the default behavior.
Comment 2 Neil Horman 2004-08-02 16:16:29 EDT
wow, I was not paying attention when I wrote that last update.  To
clarify, currently syslog forks a child.  The parent, upon return from
fork, registers to catch SIGTERM, and then sleeps for 300 seconds. 
The child (which becomes the daemon process), returns from fork,
parses the config file, and then sends a SIGTERM to the parent, to
notify the parent that the child is running and configured.  The
problem is that sometimes the child can run before the parent.  This
means that its possible that the parent has not yet registered to
receive SIGTERM when the child sends it.  The result is unexpected
exit codes from the parent, which lead to the problems described.  My
patch above reverses this order so that the parent is ready to receive
the signal before the child is ever created.  The child then resets
its own signal table to preform the default action for SIGTERM after
the fork.
Comment 3 Jason Vas Dias 2004-08-02 18:35:08 EDT
I was unable to duplicate this bug, but I agree
there is a race condition here which may be found
on multi-processor systems, and the patch can 
do no harm.
Patch applied in sysklogd-1.4.1-22 .
Comment 4 Jason Vas Dias 2004-08-04 10:21:59 EDT
*** Bug 123906 has been marked as a duplicate of this bug. ***
Comment 5 Jason Dixon 2004-08-04 11:28:26 EDT
Patch works great, thanks!  Upgraded from the base sysklogd package on
RHAS 3, no problems at all.
Comment 6 Jason Vas Dias 2004-08-16 17:26:44 EDT
*** Bug 97078 has been marked as a duplicate of this bug. ***
Comment 7 Tim Powers 2005-05-19 19:19:09 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-087.html

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