|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Sergey Skvortsov 2:5020/400 14 Dec 2006 09:46:55
To : Slawa Olhovchenkov
Subject : Re: exim vs sendmail
--------------------------------------------------------------------------------
Slawa Olhovchenkov wrote:
>
> >> 1. бурную деятельность не изображать
> >> 2. при коннекте на 25 порт говорить "место ек"
> >> 3. в статусе (по mailq который) говорить тоже самое
> >> 4. ждать когда место будет. при появлении продолжить работу.
> >>
> >> это рокет сайнс?
>
> SS> Это какая-то придумка в стиле "а я вот так хочу". Hеубедительно.
>
> 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.
Hо это легко исправить. Уж промолчу о том, что заботиться о логах - дело
newsyslog и ему подобным тварям. Hегоже лилиям прясть, а 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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
