Может кто-нибудь уточнить, что произойдет, если sendmail
демон находится в процессе обработки сообщения, когда он получает kill -15
запрос? Завершит ли он обработку сообщения, над которым работает? Или немедленно прекратить?
Я пытаюсь определить, будет ли sendmail корректно завершать соединения при запуске service sendmail restart
.
Мне нравится ответ @ Law29, и я, скорее всего, выберу его как лучший ответ на этот вопрос. При этом, если кто-то еще наткнется на этот пост, вот авторитетный ответ из летучей книги:
SIGTERM
Очистить и закрыть сигнал sendmail.
Каждый раз, когда sendmail получает сигнал SIGTERM (как было бы, если бы система была выключена), он пытается завершить работу без ошибок.
Во-первых, он разблокирует любой обрабатываемый в очереди файл. Это приводит к отмене доставки, так что сообщение будет повторено, когда система вернется к работе. Затем sendmail сбрасывает свой идентификатор на тот, под которым он изначально работал. Это приводит к тому, что учетные записи правильно показывают, что sendmail был запущен тем же пользователем, что и завершился. Наконец, sendmail завершает работу с EX_OK, несмотря ни на что, поэтому ошибки не будут возникать во время завершения работы.
Sendmail и все другие правильно написанные MTA написаны так, что есть только две возможности:
В случае возникновения ошибки у этого метода есть три результата:
Таким образом, режим отказа является «отказоустойчивым»: если отправляющая сторона не может определить, была ли ответственность за сообщение успешно передана принимающей стороне, то она отправит снова, даже если это может привести к дублированию почты в почтовый ящик получателя.
Единственный случай, когда сообщение может быть потеряно, - это серьезный сбой на сервере (сбой диска или безвозвратная потеря машины), когда он несет ответственность за почту.
Я только что протестировал 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 для отправки на свой смарт-хост, получат ошибку, и тогда это приложение будет снова отправлять почту. Предупреждение о спойлере: обычно они этого не делают, но эффект такой же, как если бы почтовый сервер уже был выключен, когда они пытались отправить.