Re: exim vs sendmail

From

Sergey Skvortsov (2:5020/400)

To

Slawa Olhovchenkov

Date

2006-12-14T08:46:54Z

Area

RU.UNIX.BSD

From: Sergey Skvortsov <skv@protey.ru>

Slawa Olhovchenkov wrote:
> 
>  >> 1. бурную деятельность не изображать
>  >> 2. при коннекте на 25 порт говорить "место ек"
>  >> 3. в статусе (по mailq который) говорить тоже самое
>  >> 4. ждать когда место будет. при появлении продолжить работу.
>  >>
>  >> это рокет сайнс?
> 
>  SS> Это какая-то придумка в стиле "а я вот так хочу". Неубедительно.
> 
>  SS> Читай документацию. Hint: check_spool_space, check_spool_inodes,
>  SS> check_log_space. Лучше документированного opensource MTA чем exim нет в
>  SS> природе.
> 
>  SS> И докажи, что предложенные тобой настройки по умолчанию будут лучше чем
>  SS>  0. Вот эти числа каждый админ пусть сам выбирает.
> 
> Это не важно какие числа, важна логика. А логика настройками не меняется.

Вообще-то, если ты выставишь check_log_space/check_spool_space, то Exim
честно будет выдавать 452 ошибку при превышении лимита.

Более того, check_log_space нужен только если логи лежат на другом
разделе, отличном от раздела со spool'ом.

Далее, если указывается параметр SIZE в команде MAIL, то будет
требоваться на диске как минимум check_spool_space+SIZE.

Короче, единственная неувязка по умолчанию (исходя из твоих ожиданий) -
то, что check_log_space равен 0.

Но это легко исправить. Уж промолчу о том, что заботиться о логах - дело
newsyslog и ему подобным тварям. Негоже лилиям прясть, а Exim'у думать о
работе явно внешних guardian'ов.

В качестве же общих размышлений стоит отметить, что в таких случаях
"должное" поведение сервисов можно разбить на два взаимоисключающих вида:

1. robustness любой ценой. Если нет ресурсов - жить по принципу
"приказано выжить", тупо ожидая появления ресурсов, и переходить на
режим экономии (degradation of service quality). В данном случае -
выдавать temporary error, в случае HTTP - типа 503 с заголовком
Retry-after (жаль, что в SMTP нет такого аналога).

2. ни одного запроса без логов. Как пример крайнего случая - это когда
ОС с включенным аудитом принципиально умирает, если для логов аудита нет
места. В этом смысле syslog вообще нехорош, ибо логи могут потеряться, а
 никто об этом не узнает.

С практической точки зрения первый вариант удобнее, поскольку о крайних
ситуациях нехватки ресурсов думает каждый сервис по отдельности, а
админ... ну скажем спит. В реальности же, за "здоровьем" системы всё же
должны следить отдельные сущности, и уж если ресурсы действительно
кончились, несмотря на все усилия "служб спасения" - то да, сервисам
логично умереть, и ожить лишь по внешнему приказу (всё тех же
guardian'ов, которые должны поднять сервисы когда ресурсы появятся).

Как итог, всё же не следует ожидать от каждого сервиса навыков выживания
в пустыне, уж лучше продумать всё загодя.

-- 
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 50/12 400/814 450/159 1024 461/43 132 640 469/999 4616/3 4625/8
SEEN-BY: 4641/444 5000/76 5000 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28
SEEN-BY: 5019/26 5020/18 175 194 400 545 982 1057 1909 1922 2238 2395 2871
SEEN-BY: 5020/4441 5021/29 5025/3 5026/14 45 5027/12 5030/1080 1957 5034/10 13
SEEN-BY: 5035/3 38 5036/1 5045/7 5049/1 5051/15 5054/1 4 8 9 11 28 35 36 37 45
SEEN-BY: 5054/66 67 70 75 84 85 5059/9 5060/88 5061/15 5062/10 5063/3 5064/7
SEEN-BY: 5066/18 5075/5 5076/1 5077/70 5080/1003 5084/9 5085/13 5095/20
SEEN-BY: 5096/18 6001/10

PATH: 5020/400 545 5054/1 37