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

...

...

OK, so the first place to look then, would be the service init script (which for RHEL/CentOS is usually under /etc/init.d/sendmail)

The restart sequence runs this portion of the script:

    reload() {
        updateconf
        echo -n $"Reloading $prog: "
        killproc sendmail -HUP
        RETVAL=$?
        echo
        if [ $RETVAL -eq 0 -a -f /var/run/sm-client.pid ]; then
            echo -n $"reloading sm-client: "
            killproc sm-client -HUP
            RETVAL=$?
            echo
        fi
        return $RETVAL
    }

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 SIGTERM (AKA kill -15). The PID is contained in the first line of /var/run/sendmail.pid.

2) Start the daemon using the exact same startup params. The complete command (including startup params) are contained in the last line of /var/run/sendmail.pid.

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):

SIGTERM

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.