An interesting question came up the other day: What exactly does the sendmail daemon do with SMTP sessions that are in progress when it needs to restart?
For the purpose of discussion, let's assume that it's being restarted via
service sendmail restart. I'll wait a moment for admins to scream at their monitors about this being outdated with the introduction of
OK, so the first place to look then, would be the service init script (which for RHEL/CentOS is usually under
The restart sequence runs this portion of the script:
echo -n $"Reloading $prog: "
killproc sendmail -HUP
if [ $RETVAL -eq 0 -a -f /var/run/sm-client.pid ]; then
echo -n $"reloading sm-client: "
killproc sm-client -HUP
The key part here is
killproc sendmail -HUP. That leverages the
killproc function in
/etc/init.d/functions to send a HUP ("hangup") signal to the process. I'll refrain from digressing but the general logic behind that
killproc is actually pretty cool. Check it out sometime. :-)
Annnnnnnnnnyway, what does sendmail actually do with that signal? That depends on the version of sendmail but at/after 8.7, it would do the following:
1) Kill the running daemon by issuing a
kill -15). The PID is contained in the first line of
2) Start the daemon using the exact same startup params. The complete command (including startup params) are contained in the last line of
OK. We're nearly done, I promise. :-)
So now we know that, ultimately, the daemon is being sent a
SIGTERM signal. What does THAT do? What is the impact on mail processing? Each process/vendor is different but in the case of sendmail, it does the following (explained courtesy of the bat book):
Cleanup and exit sendmail signal.
Whenever sendmail gets a SIGTERM signal (as would be the case if the system were being shut down), it tries to exit cleanly.
First, it unlocks any queued file it is processing. This has the effect of canceling delivery so that the message will be tried again when the system comes back up. Then sendmail resets its identity to the identity it originally ran under. This causes accounting records to correctly show that the same user sendmail started as has exited. Finally, sendmail exits with EX_OK, no matter what, so that errors will not be produced during shutdown.
As far as I can tell (and in limited testing), the daemon does NOT wait for SMTP sessions to finish. So if a SMTP session is in the middle of delivery, the TCP session is closed and the upstream mail server will requeue/retry as per their configuration.
So, after this long-winded post, the bottomline is that SMTP connections DO get dropped during a restart but that ultimately shouldn't cause any issues if the upstream mail relay is RFC complaint and configured to requeue.