[syslog-ng]conflict with redhat init scripts

[Balazs Scheidler]

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