write-timeout

<acct-file>

Сколько ждать программу-приёмник при записи
в конфигурации это строкаwrite-timeout 1mвнутри блока <acct-file>
Чтобы чужая программа не держала почтовый узел

Строка ограничивает ожидание при записи в программу, которой отдаются записи учёта. Умолчание — 1m, и применяется она только к форме с каналом.

Смысл в одном слове — «неотвечающая». Программа-сборщик может не упасть, а просто перестать читать: зависнуть, упереться в свою базу, уйти в бесконечный цикл. Без порога узел ждал бы её сколько угодно, и учёт держал бы почту.

Порог и перезапуск — пара. Этот ограничивает одну запись, retry-interval назначает следующую попытку после срыва.

Минута — это много. Для почтового узла минутная пауза на записи учёта ощутима, и на потоке порог обычно снижают.

Главная ловушка — принять умолчание за безопасное значение. Минута на каждую запись при зависшем сборщике складывается в заметную задержку. Если сборщик свой и быстрый, порог стоит снизить до секунд.
Что делает Хаб. Не пишет и форму с каналом не использует.

Тот же принцип у нас соблюдён в другом месте: приёмник телеметрии отвечает сразу и разбирает пачку в фоне — именно чтобы не держать чужой почтовый узел. Здесь порог решает ту же задачу со стороны узла.

Рекомендуемые значения

Порог соразмеряют со скоростью сборщика:

Значение Когда
1m (умолчание) сборщик чужой, поведение неизвестно
5s–10s сборщик свой и быстрый

Срыв записи не теряет данные молча — он запускает механизм перезапуска, но промежуток всё равно не сохраняется.

Умолчание 1m и назначение (не давать неотвечающему приложению держать узел) — из руководства (§ 3.3.11.9). Совет снижать порог для своего сборщика — наш.
Пример в конфигурации
# свой быстрый сборщик — порог в секундах, а не в минуту
<acct-file |/usr/local/bin/collector.pl>
    write-timeout 10s    retry-interval 1m
</acct-file>
Две строки работают в паре: первая обрывает зависшую запись, вторая назначает следующую попытку.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается1 ошибка▶

Поднимают порог вместо того, чтобы ускорить сборщик

наш опыт

Чем чреватоУзел ждёт дольше, и учёт начинает влиять на отправку почты. Причина — синхронная обработка в сборщике — остаётся.
Как заметитьПорог поднимали уже дважды, и каждый раз ненадолго помогало.
Как правильноПереписать сборщик: принять запись, ответить, обработать в фоне.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
write-timeout <time-interval>
Значения
интервал времени
Умолчание
1m § 3.3.11.9
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<acct-file>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри своего <acct-file> и применяется, только когда этот блок отдаёт записи программе.
Как проверить на узле
Срывы по порогу MTA пишет в свой журнал:
grep -i "timeout" /var/log/pmta/log | tail -20
Регулярные срывы означают, что сборщик не поспевает. Поднимать порог — временная мера; правильнее сделать так, чтобы он принимал быстро и обрабатывал в фоне.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Собрать телеметрию