exim vs sendmail

From

Slawa Olhovchenkov (2:5030/500)

To

Sergey Skvortsov

Date

2006-12-14T09:23:56Z

Area

RU.UNIX.BSD

Hello Sergey!

14 Dec 06, Sergey Skvortsov writes to Slawa Olhovchenkov:

 >> Это не важно какие числа, важна логика. А логика настройками не меняется.

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

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

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

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

Ну какая нафиг разница, а?
Ну а так он при 0 на log выдает 452, да?
Меня это в принципе устравивает, если он не выходит.

Я не знаю что там дальше случается, может ему не удается записать ругань в лог (когда место стало совсем отрицательным), но он в конце концов сдыхает. И вот это мне не нравится.

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

Они и позаботятся. Но потом. И место у него быдет. Дохнуть-то зачем?

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

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

Ну типа.

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

В принципе не противоречит, если смягчить до "ни одного существенного запроса". Типа коннекты которые мы намерянны игнорировать все и всегда -- можно и не логировать.

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


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

Я предпочитаю что бы сервисы не дохли от плохой погоды. А то у каждого своя придурь, некоторые дохнут от отсутствия внешнего dns.

... Я yгадаю этy пpогpаммy с 7 байт!
--- GoldED+/BSD 1.1.5
 * Origin:  (2:5030/500)
SEEN-BY: 50/12 203 400/814 450/186 1024 451/30 469/418 550/196 4614/20 4635/4
SEEN-BY: 5000/5000 5011/13 5012/46 5015/28 5019/26 5020/154 175 400 545 549
SEEN-BY: 5020/758 1523 1604 1630 2142 2238 2395 2450 2590 2871 4441 5021/3 29
SEEN-BY: 5022/128 5025/3 750 5027/12 5029/32 5030/49 500 556 966 1063 1080
SEEN-BY: 5030/1900 1957 2828 5031/47 70 5035/38 5040/47 5042/13 5045/7 5049/50
SEEN-BY: 5049/97 5054/1 4 8 9 11 28 35 36 37 45 66 67 70 75 84 85 5059/9 37
SEEN-BY: 5062/1 10 5063/3 5064/7 5076/1 5077/70 5080/80 1003 5082/6 5083/21
SEEN-BY: 5084/9 5085/13 5090/108 5094/4 5095/20 5096/18 5099/11 6001/10

PATH: 5030/500 5020/4441 545 5054/1 37