Назад | Перейти на главную страницу

Что именно делает демон sendmail, когда получает запрос kill -15 (SIGTERM)? Как это влияет на сообщения, которые находятся в пути?

Может кто-нибудь уточнить, что произойдет, если sendmail демон находится в процессе обработки сообщения, когда он получает kill -15 запрос? Завершит ли он обработку сообщения, над которым работает? Или немедленно прекратить?

Я пытаюсь определить, будет ли sendmail корректно завершать соединения при запуске service sendmail restart.

Мне нравится ответ @ Law29, и я, скорее всего, выберу его как лучший ответ на этот вопрос. При этом, если кто-то еще наткнется на этот пост, вот авторитетный ответ из летучей книги:

SIGTERM

Очистить и закрыть сигнал sendmail.

Каждый раз, когда sendmail получает сигнал SIGTERM (как было бы, если бы система была выключена), он пытается завершить работу без ошибок.

Во-первых, он разблокирует любой обрабатываемый в очереди файл. Это приводит к отмене доставки, так что сообщение будет повторено, когда система вернется к работе. Затем sendmail сбрасывает свой идентификатор на тот, под которым он изначально работал. Это приводит к тому, что учетные записи правильно показывают, что sendmail был запущен тем же пользователем, что и завершился. Наконец, sendmail завершает работу с EX_OK, несмотря ни на что, поэтому ошибки не будут возникать во время завершения работы.

Sendmail и все другие правильно написанные MTA написаны так, что есть только две возможности:

  1. сообщение сначала записывается на диск, а затем подтверждается отправляющим MTA
  2. сообщение не подтверждено

В случае возникновения ошибки у этого метода есть три результата:

  1. Ошибка возникает до того, как получатель sendmail попытался ее подтвердить. Отправляющая сторона повторяет попытку.
  2. Ошибка возникает после того, как получающий sendmail попытался подтвердить ее, но до того, как отправляющая сторона получит подтверждение. Обычно это происходит, если пакет подтверждения теряется в сети. Отправляющая сторона повторяет попытку, но принимающая сторона обрабатывает почту. Сообщение будет продублировано.
  3. Ошибка возникает после того, как отправляющая сторона получает подтверждение. Принимающая сторона несет ответственность за правильную обработку почты.

Таким образом, режим отказа является «отказоустойчивым»: если отправляющая сторона не может определить, была ли ответственность за сообщение успешно передана принимающей стороне, то она отправит снова, даже если это может привести к дублированию почты в почтовый ящик получателя.

Единственный случай, когда сообщение может быть потеряно, - это серьезный сбой на сервере (сбой диска или безвозвратная потеря машины), когда он несет ответственность за почту.

Я только что протестировал sendmail 8.14.9, и когда я выполняю остановку /etc/init.d/sendmail, которая на этой машине реализована killall ${SENDMAIL_HOME}/bin/sendmail, который отправляет kill -15 вы спрашиваете, письма, входящие в данный момент на этапе DATA, прерываются. Сеанс TCP закрывается сервером.

На этой машине restart реализуется stop ; start, поэтому ответ на ваш вопрос: нет, перезапуск не изящный, но (конечно) письма не будут потеряны так долго как они отправляются RFC-совместимой реализацией SMTP или в нее.

Это звучит так, как будто этого никогда не произойдет, но (скажем) приложения PHP или Java, использующие некоторую почтовую библиотеку SMTP для отправки на свой смарт-хост, получат ошибку, и тогда это приложение будет снова отправлять почту. Предупреждение о спойлере: обычно они этого не делают, но эффект такой же, как если бы почтовый сервер уже был выключен, когда они пытались отправить.