conflict with redhat init scripts
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) Thanks, Michael P.S. If anyone is interesting in doing the same source-diving that I've been doing, you can get the same things I've been using from: http://mirror.dulug.duke.edu/ mirror/dulug/dulug-7.1/SRPMS/dulug/syslog-ng-1.4.11-3.src.rpm http://mirror.dulug.duke.edu/ mirror/redhat/redhat-7.1/en/os/i386/SRPMS/initscripts-5.83-1.src.rpm source rpms can be unpacked to an arbitrary tmpdir with the following commands: SRCDIR=$HOME/tmp mkdir -p $SRCDIR/usr/src/redhat rpm --root $SRCDIR --install syslog-ng-1.4.11-3.src.rpm cd $SRCDIR/usr/src/redhat/SOURCES/ The rest should be obvious. -- Michael Stenner Office Phone: 919-660-2513 Duke University, Dept. of Physics mstenner@phy.duke.edu Box 90305, Durham N.C. 27708-0305
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
I was successfully running syslog-ng-1.4.12 on a Redhat 7.1 system under kernel 2.4.2-2. After upgrading the kernel to 2.4.6, syslog-ng starts OK, but dies immediately. There are no error messages in the logs. When started from the command line there are error messages " Error creating AF_INET socket (Network is unreachable)" and "Error initializing configuration, exiting".
I was successfully running syslog-ng-1.4.12 on a Redhat 7.1 system under kernel 2.4.2-2. After upgrading the kernel to 2.4.6, syslog-ng starts OK, but dies immediately. There are no error messages in the logs.
When started from the command line there are error messages " Error
creating
AF_INET socket (Network is unreachable)" and "Error initializing configuration, exiting".
Problem was traced to an ethernet card.
Could somebody explain what are this source and destination items ?? ( look in cfg-lex.c ) "door",KW_DOOR "remote_control",KW_REMCTRL are they supposed to do something or are just garbage ? Amodiovalerio Verde Sysadmin, Consultant E-business and Internet Security Specialist amover@wipsrl.it
On Mon, Jul 24, 2000 at 02:59:59PM +0200, Amodiovalerio Verde wrote:
Could somebody explain what are this source and destination items ?? ( look in cfg-lex.c )
"door",KW_DOOR "remote_control",KW_REMCTRL
are they supposed to do something or are just garbage ?
door is an option to streams sources used on Solaris 2.6 and later. remote_control is a new feature in 1.5.8 which can be used to reopen files during runtime without having the reinitialize your whole configuration. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
On Mon, Jul 24, 2000 at 02:59:59PM +0200, Amodiovalerio Verde wrote:
Could somebody explain what are this source and destination items ?? look in cfg-lex.c )
"door",KW_DOOR "remote_control",KW_REMCTRL
are they supposed to do something or are just garbage ?
door is an option to streams sources used on Solaris 2.6 and later. remote_control is a new feature in 1.5.8 which can be used to reopen files during runtime without having the reinitialize your whole configuration.
-- Bazsi
Can you explain this a little further ? I'm going to write an italian syslog-ng howto and i'd like to put all options, like undocumented one like door and remote_control. thx. Valerio Verde
"door",KW_DOOR "remote_control",KW_REMCTRL
are they supposed to do something or are just garbage ?
door is an option to streams sources used on Solaris 2.6 and later. remote_control is a new feature in 1.5.8 which can be used to reopen files during runtime without having the reinitialize your whole configuration.
-- Bazsi
Can you explain this a little further ? I'm going to write an italian syslog-ng howto and i'd like to put all options, like undocumented one like door and remote_control. thx.
remote_control is a destination driver, and as such you can direct messages to it (from sources, and possibly filter it using filters). if a message goes to remote_control, and its message part should contain a filename, if that given file is opened by syslog-ng it's first closed, and opened again. Thus you can reopen files without fully reinitializing syslog-ng by sending it a -HUP signal. I think door is documented, it is used with streams sources under Solaris. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
participants (4)
-
Amodiovalerio Verde
-
Balazs Scheidler
-
Gorm Jensen
-
Michael Stenner