当 sendmail 守护进程收到 kill -15 (SIGTERM) 请求时，它具体会做什么？这会对正在传输的消息产生什么影响？

Question

有人能详细说明一下，如果sendmail守护进程在处理消息的过程中收到请求，会发生什么kill -15吗？它会完成正在处理的消息的处理吗？还是立即终止？

我试图确定当我运行时 sendmail 是否会正常结束连接service sendmail restart。

Answer 1

Sendmail 和所有其他正确编写的 MTA 都是这样编写的，因此只有两种可能性：

1. 邮件首先写入磁盘，然后向发送 MTA 确认
2. 消息未被确认

使用此方法，如果发生错误，则会出现三种结果：

1. 接收方 sendmail 尝试确认错误之前发生错误。发送方将重试。
2. 错误发生在接收方 sendmail 尝试确认之后，但在发送方收到确认之前。如果确认数据包在网络上丢失，则基本上会发生这种情况。发送方会重试，但接收方会处理邮件。消息将被复制。
3. 错误发生在发送方收到确认后。接收方有责任正确处理邮件。

因此，故障模式是“故障安全”的：如果发送方无法确定消息的责任是否已成功转移到接收方，则它将再次发送，即使这可能会导致收件人的收件箱中邮件重复。

唯一会丢失消息的情况是，当负责邮件的服务器发生严重故障（磁盘故障或机器永久丢失）时。

我刚刚在 sendmail 8.14.9 上进行了测试，当我执行 /etc/init.d/sendmail stop（此机器上由 实现）时killall ${SENDMAIL_HOME}/bin/sendmail，它会发送kill -15您询问的邮件，当前处于 DATA 阶段的传入邮件将被中止。服务器将关闭 TCP 会话。

在这台机器上，restart是由 实现的stop ; start，所以你的问题的答案是，不，重启不是正常的，但（当然）不会丢失任何邮件只要它们正由符合 RFC 标准的 SMTP 实现发送或者发送给符合 RFC 标准的 SMTP 实现。

这听起来好像永远不会发生，但（比如说）使用某些 SMTP 邮件库向其智能主机发送邮件的 PHP 或 Java 应用程序将收到错误，然后由该应用程序重新发送邮件。剧透警告：它们通常不会这样做，但效果就像它们尝试发送时邮件服务器已经关闭一样。

Answer 2

我喜欢@Law29的回复，可能会选择它作为这个问题的最佳答案。话虽如此，以防其他人偶然发现这篇文章，以下是权威答案摘自蝙蝠书：

信号终端

清理并退出 sendmail 信号。

每当 sendmail 收到 SIGTERM 信号时（就像系统关闭的情况一样），它都会尝试干净地退出。

首先，它会解锁正在处理的所有排队文件。这样可以取消传送，以便在系统恢复时再次尝试传送消息。然后 sendmail 将其身份重置为最初运行时的身份。这样，记帐记录就会正确显示启动 sendmail 的同一用户已退出。最后，无论如何，sendmail 都会以 EX_OK 退出，这样在关机期间就不会产生错误。