On Fri, Jul 13, 2001 at 08:46:56AM -0400, Michael Stenner wrote:
I'm using syslog-ng 1.4.11 on a redhat 7.1 machine and have discovered a conflict involving the way syslog-ng forks and exits, and the way redhat starts its daemons. I don't think either end is really doing anything wrong here, but I think some things could be tidied up a bit.
Basically, I think it comes from the fact that when syslog-ng forks, the parent waits for the child to send it a SIGTERM, and then dies with exit code 0. Unfortunately, I think that initlog (the redhat tool for starting daemons and logging the results) is thinking that the daemon was sent an uncaught SIGTERM and is dying.
Let me give you some examples of what I mean.
When you use bash to start syslog-ng and then print the "exit status", $?, bash reports 143. From the bash manpage:
When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status.
143 - 128 = 15 = SIGTERM
When you use initlog to start syslog-ng, initlog returns 15 directly. It also logs (via syslog-ng, humorously) that syslog-ng failed to start. Consequently, the init script reports failure.
I'm still confused about a couple of things.
1) I've trolled through the syslog-ng source, and It's clear that the TERM signal _should_ be caught, so why are bash and initlog detecting this?
2) I've trolled through the initlog source, and I can't find where initlog tries to detect the type of signal a program received, or even that it cares. As far as I can tell, it just looks for the exit value of the program.
As you can see, I'm already hip-deep in both programs, so I'm certainly willing to try and help "fix" this. I'm just wondering about these last two points, and which end it would be best to fix it on. (the fact that bash reports as it does leads me to lean toward changing this behavior in syslog-ng)
The problem is that syslog-ng had a bug, occurring only on kernels 2.4. I suppose you are running kernel 2.4. The fix is included in syslog-ng 1.4.12. (SIGTERM handler was setup after fork) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1