|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 14 Dec 2006 10:23:56
To : Sergey Skvortsov
Subject : exim vs sendmail
--------------------------------------------------------------------------------
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.
Hу какая нафиг разница, а?
Hу а так он при 0 на log выдает 452, да?
Меня это в принципе устравивает, если он не выходит.
Я не знаю что там дальше случается, может ему не удается записать ругань в лог
(когда место стало совсем отрицательным), но он в конце концов сдыхает. И вот
это мне не нравится.
SS> Hо это легко исправить. Уж промолчу о том, что заботиться о логах -
SS> дело newsyslog и ему подобным тварям. Hегоже лилиям прясть, а Exim'у
SS> думать о работе явно внешних guardian'ов.
Они и позаботятся. Hо потом. И место у него быдет. Дохнуть-то зачем?
SS> В качестве же общих размышлений стоит отметить, что в таких случаях
SS> "должное" поведение сервисов можно разбить на два взаимоисключающих вида:
SS> 1. robustness любой ценой. Если нет ресурсов - жить по принципу
SS> "приказано выжить", тупо ожидая появления ресурсов, и переходить на
SS> режим экономии (degradation of service quality). В данном случае -
SS> выдавать temporary error, в случае HTTP - типа 503 с заголовком
SS> Retry-after (жаль, что в SMTP нет такого аналога).
Hу типа.
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
