0

Can someone elaborate on what would happen if the sendmail daemon is in the middle of processing a message when it receives a kill -15 request? Would it finish processing whatever message it's working on? Or terminate immediately?

I'm trying to determine if sendmail will gracefully end connections when I run service sendmail restart.

Mike B
  • 11,871
  • 42
  • 107
  • 168

2 Answers2

1

Sendmail and all other properly written MTAs are written so that there are are only two possibilities:

  1. the message is first written to disk and then acknowledged to the sending MTA
  2. the message is not acknowledged

With this method, there are three outcomes in case an error occurs:

  1. The error occurs before the receiving sendmail has tried to acknowledge it. The sending party retries.
  2. The error occurs after the receiving sendmail has tried to acknowledge it, but before the sending party receives the acknowledgement. This basically happens if the acknowledgement packet is lost on the network. The sending party retries but the receiving party will process the mail. The message will be duplicated.
  3. The error occurs after the sending party receives the acknowledgement. The receiving party has the responsibility for processing the mail correctly.

The failure mode is therefore "fail-safe": if the sending party cannot determine whether responsibility for the message has been successfully transferred to the receiving party, then it will send again, even though this may result in the duplication of the mail in the recipient's inbox.

The only case in which a message can be lost is if there is a severe failure on the server (disk failure or permanent loss of the machine) while it has responsibility for the mail.

I have just now tested on sendmail 8.14.9, and when I do an /etc/init.d/sendmail stop, which on this machine is implemented by killall ${SENDMAIL_HOME}/bin/sendmail, which sends the kill -15 you are asking about, the mails currently incoming in DATA phase are aborted. The TCP session is closed by the server.

On this machine, restart is implemented by stop ; start, so the answer to your question is that no, the restart is not graceful, but (of course) no mails will be lost as long as they are being sent by or to an RFC-compliant implementation of SMTP.

This sounds like it could never happen, but (say) PHP or Java applications using some SMTP mail library to send to their smarthost will receive an error, and it is then up to that application to send the mail again. Spoiler alert: they usually don't, but the effect is the same as if the mail server was already shut down when they tried to send.

Law29
  • 3,557
  • 1
  • 16
  • 28
1

I like @Law29's response and will likely choose it as the best answer for this question. That being said, in case someone else stumbles across this post, here's the authoritative answer from 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.

Mike B
  • 11,871
  • 42
  • 107
  • 168
  • True, I should have checked the bat book :) It's a pity that there is no option as far as I can see to inhibit new transactions while finishing ones already in progress. This could be useful behind a load-balancer. – Law29 Jun 27 '16 at 16:50