Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 14411 - /etc/init.d/sendmail FAILS to stop sendmail for 8.12.7-r1
Summary: /etc/init.d/sendmail FAILS to stop sendmail for 8.12.7-r1
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High critical (vote)
Assignee: Nick Hadaway
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-23 03:00 UTC by Alessandro Pisani
Modified: 2003-04-04 01:26 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alessandro Pisani 2003-01-23 03:00:19 UTC
bundled /etc/init.d/sendmail file is wrong so it fails to both kill the sendmail
queue runner introduced in 8.12.7 ebuild and also to kill sendmail itself.
this is particulary dangerous for fs at halt/reboot.

below there is the corrected file, please apply urgently.
(please note that the -9 in kill is needed to make the script successfully kill
sendmail)

<--- cut here --->
#!/sbin/runscript
# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License, v2 or later
# $Header: /home/cvsroot/gentoo-x86/net-mail/sendmail/files/sendmail,v 1.5
2003/01/20 01:49:24 raker Exp $

. /etc/conf.d/sendmail

depend() {
	need net
	use logger
}

start() {
	ebegin "Starting sendmail"
	/usr/bin/newaliases > /dev/null 2>&1
	(cd /var/spool/mqueue; rm -f xf*)
	/usr/sbin/sendmail ${SENDMAIL_OPTS} > /dev/null 2>&1
	/usr/sbin/sendmail ${CLIENTMQUEUE_OPTS} > /dev/null 2>&1
	eend $?
}

stop() {
	ebegin "Stopping sendmail"
	kill -9 `sed -n -e '1p' ${PIDFILE}`
	kill -9 `sed -n -e '1p' ${CM_PIDFILE}`
	eend $?
}
<--- --- ---- --->

bye,
Alessandro
Comment 1 Nick Hadaway 2003-01-23 03:55:32 UTC
added the -9.  Thanks for the suggestion.
Comment 2 Alessandro Pisani 2003-01-23 03:58:28 UTC
please note that the problem is not only related to the -9: the original script
missed the "kill -9 `sed -n -e '1p' ${CM_PIDFILE}`" line!

bye,
Alessandro
Comment 3 Alessandro Pisani 2003-01-23 04:01:57 UTC
i think that a -r2 should be done due to this fix, otherwise a lot of system
won't get updated :-/

bye,
Alessandro
Comment 4 Blu3 2003-01-23 08:50:23 UTC
_Please_ don't do this.  It's very bad form to kill -9 a daemon.  Sendmail has
good reason for not exiting immediately, transactions are probably still in
progress.  If you look carefully you should see that the sendmail {accepting
connections} parent has exited and the children are finishing up their tasks
(properly aborting the sessions).

Having run sendmail for about 10 years now, I vary _rarely_ run into problems
with sendmail not exiting.

All sendmail children will exit and terminate their sessions uncleanly when sent
the TERM signal.  When the system is shutting down, init will send all remaining
processes the TERM signal followed by the KILL signal.

If you want to send all processes in the process group the TERM signal, send
-PID instead of PID, ref: man page for kill.  e.g. kill -TERM -$(sed -n '1p'
$PIDFILE).  If you really really must, follow that up with an skill sendmail to
abort the in-process sessions.  Just don't use -9, it isn't needed and it's
dangerous.  It only takes a few seconds longer to wait for the children to
terminate.  Is it that important to exit ASAP, almost guaranteeing data loss or
corruption?

If you kill a process with -9, it has no chance to properly clean up and exit. 
You risk loss of data and corruption of data.  Particularly with sendmail
installations that are using databases which are becoming much more common than
flat files.
Comment 5 Alessandro Pisani 2003-01-23 15:18:59 UTC
UHm...that's true... kill -9 is brute force... thanks Blu3
reopening the bug: Nick can you please fix this?

bye,
Alessandro
Comment 6 Alessandro Pisani 2003-01-23 15:46:17 UTC
i've just noticed that futhermore my previous solution was unable to kill the
queue runner...

Is it okay to replace them with ?
killall sendmail
rm -f ${PIDFILE} ${CM_PIDFILE}

any signals expert there?
bye,
Alessandro
Comment 7 Nick Hadaway 2003-01-23 16:05:05 UTC
Here was my thought process for considering this... Part of what I thought I
understood about Sendmail was the fact that during a transfer the queued message
isn't deleted.  So if a process stops at any point in time... the original
queued message is still in a state of "i haven't been sent yet"... 

Regardless of this possibility, you are probably right about the -9 being
dangerous.  I guess really I just needed people to speak up.  :)

As a workaround to appease both sides of the tracks I am going to add a KILLOPTS
variable to the ebuild so those who want the original safer kill can have a more
reliable site and those who just want fast reboots can force their process'
death quickly can specify -9...  And for the middle of the road, -15?

killall sendmail will definitely work, and I use that on my own custom sendmail
init script on a non-gentoo system and I haven't experienced problems yet...
does anybody have a reason to oppose using killall sendmail?  I think killall
passes a -9???  I'm not sure though...
Comment 8 Alessandro Pisani 2003-01-23 16:12:37 UTC
killall passes SIGTERM if no signal is specified

bye,
Alessandro
Comment 9 Alessandro Pisani 2003-01-24 04:18:45 UTC
i think that sendmail-8.12.7-r2 (the one with kill -9) should be masked for x86
(~x86)
testing -r3 ...

bye,
Alessandro
Comment 10 Alessandro Pisani 2003-01-24 17:42:44 UTC
tried -r3 ... it is still unable to properly kill the queue runner on
reboot/halt...don't know why :|

the only solution I found to fix this is to use killall.
i propose this solution, which now includes also the KILL_OPTS change and a
safer removal of the pidfiles (safer, i mean, than my previous version) :

stop() {
	ebegin "Stopping sendmail"
        killall ${KILL_OPTS} sendmail

        # make sure pid files are deleted only if processes had been killed
        if [ -z "`ps -ef | grep sendmail: | grep -v grep`" ]; then
            rm -f ${PIDFILE} ${CM_PIDFILE}
        fi

	eend $?
}

bye,
Alessandro
Comment 11 Nick Hadaway 2003-01-29 18:21:13 UTC
-r4 has been added to portage which utilizes killall.  Please test this new revision and let me know if you have any further problems.
Comment 12 Alessandro Pisani 2003-02-01 15:27:04 UTC
Nick: no, your new script for -r4 is wrong: killall /usr/bin/sendmail doesn't work. On my machine I use this (it works _for me_ since about 10 days - please test it people!) :

stop() {
	ebegin "Stopping sendmail"
	killall ${KILL_OPTS} sendmail

	# check is killall was successful before removing pid files
	if [ -z "`ps -ef | grep sendmail: | grep -v grep`" ]; then
		rm ${PIDFILE} ${CM_PIDFILE}
	fi

	eend $?
}

bye,
Alessandro
Comment 13 Alessandro Pisani 2003-02-04 02:17:40 UTC
Nick: -r5 is okay for me.... btw why didn't you include the pid files removal if-block? it there any technical reason (i.e. grep not widespread available on all machines...?!) ? Just courios about it...

thank you,
Alessandro
Comment 14 John Davis (zhen) (RETIRED) gentoo-dev 2003-04-04 01:21:57 UTC
db fix
Comment 15 John Davis (zhen) (RETIRED) gentoo-dev 2003-04-04 01:26:48 UTC
db fix