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