Bug 126223
| Summary: | syslogd not handling -f option properly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Jason Dixon <jason.dixon> | ||||
| Component: | sysklogd | Assignee: | Jason Vas Dias <jvdias> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | bugzilla, herrold, ptsekov, tao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-04-20 00:09:27 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: | |||||||
| Attachments: |
|
||||||
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.
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. 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 . *** Bug 123906 has been marked as a duplicate of this bug. *** Patch works great, thanks! Upgraded from the base sysklogd package on RHAS 3, no problems at all. *** Bug 97078 has been marked as a duplicate of this bug. *** 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 |
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.