Bugzilla Bug 14411

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

added the -9.  Thanks for the suggestion.

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

i think that a -r2 should be done due to this fix, otherwise a lot of system
won't get updated :-/

bye,
Alessandro

_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.

UHm...that's true... kill -9 is brute force... thanks Blu3
reopening the bug: Nick can you please fix this?

bye,
Alessandro

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

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...

killall passes SIGTERM if no signal is specified

bye,
Alessandro

i think that sendmail-8.12.7-r2 (the one with kill -9) should be masked for x86
(~x86)
testing -r3 ...

bye,
Alessandro

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

-r4 has been added to portage which utilizes killall.  Please test this new
revision and let me know if you have any further problems.

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

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

db fix

db fix