There are plenty of times that you need to stop Qmail for maintainence purposes.
The qmailctl script generally does a good job of stopping qmail, but sometimes it does not quite shutdown all of the qmail processes.
[root@here]#
qmailctl stop
Stopping qmail…
qmail-smtpd
qmail-send
[root@here]#
qmailctl stat
/service/qmail-send: up (pid 32436) 358918 seconds, want down
/service/qmail-send/log: down 3 seconds, normally up
/service/qmail-smtpd: down 3 seconds, normally up
/service/qmail-smtpd/log: down 3 seconds, normally up
messages in queue: 142
messages in queue but not yet preprocessed: 0
As you can see from the output of qmailctl stat, the qmail-send program is still running. If you do a[1]
ps waux | grep qmail | grep -v grep
you will often find output like
[root@here]#
psq
root 55033 0.0 0.1 1196 480 ?? I Tue05PM 0:00.01 supervise qmail-send
qmails 55035 0.0 0.1 1340 760 ?? I Tue05PM 1:28.27 qmail-send
root 55036 0.0 0.1 1196 480 ?? I Tue05PM 0:00.01 supervise qmail-smtpd
qmaill 55040 0.0 0.1 1224 532 ?? I Tue05PM 0:29.48 multilog t s100000 n20 /var/log/qmail/qmail-send
root 55043 0.0 0.1 1216 500 ?? I Tue05PM 0:00.03 tcpserver -H -R -v -c100 0 110 qmail-popup
root 55048 0.0 0.1 1216 548 ?? I Tue05PM 0:00.02 qmail-lspawn ./Maildir
qmailr 55049 0.0 0.1 1284 684 ?? I Tue05PM 0:22.64 qmail-rspawn
qmailq 55050 0.0 0.1 1212 544 ?? I Tue05PM 0:04.69 qmail-clean
qmailr 83484 0.0 0.2 2432 1196 ?? I 2:38AM 0:00.00 qmail-remote yahoo.com webmaster@here.com there@yahoo.com
qmailr 83498 0.0 0.2 2432 1196 ?? I 2:38AM 0:00.01 qmail-remote hotmail.com webmaster@here.com you@yahoo.com
If you then run qmailctl start, you will often have the situation with qmail-send showing up as running for 1 second while the other qmail processes are up for much longer. Basically a second qmail-send is trying to start and is dying after a second. The first instance of qmail-send is still running and needs to be stopped.
The output often contains a mixture of qmail-send, qmail-remote, qmail-clean and others depending on how your mail has been setup and what is in the process of being sent/received when you issue the qmailctl stop command.
At this point, we can wait a bit, to see if qmail-send eventually goes down or whether we will have to kill it explicitly. It is worth trying another qmailctl stop at this point. If qmailctl stat shows qmail-send is still up, which is often the case, it is probably time to kill qmail-send directly.
I usually do a kill -9 qmail-send. Then follow it with psq to see what is still running. Often I have to run a number of kills and killalls, such as killall qmail-remote. We’re not really shutting down qmail very cleanly, but sometimes, especially when you’re in a hurry it makes sense to kill things rather than wait for them to terminate.
Eventually only the supervise scripts should be running,
[root@work]#
psq
root 561 0.0 0.0 1148 84 con- I Sat02AM 0:00.05 supervise qmail-send
root 563 0.0 0.0 1148 84 con- I Sat02AM 0:00.06 supervise qmail-smtpd
At this stage I usually call /usr/local/etc/rc.d/svscan.sh stop. The location of your actual svscan.sh script may be different from mine.
A psq shows nothing running. A sockstat -4 | grep 25 shows nothing listening on the smtp port. Now is the time to go in and do maintainance – such as recompile qmail, dequeue mail or repair the queue.
Once you’re done, starting qmail is as simple as /usr/local/etc/rc.d/svscan.sh start.
[1] Actually I use this snippet quite a bit so to save time, I’ve copied it to a file called
psq under /usr/local/bin
echo "ps waux | grep qmail | grep -v grep" > /usr/local/bin/psq
so that simply typing psq gives me a list of all the running qmail processes.