Куда узел пишет, почему не запустился

pmta-startuperr.log
Существует потому, что основной журнал может быть недоступен

Отдельный файл ровно для одного случая: MTA не запустился.

Зачем он вообще нужен. Отказ запуска бывает вызван тем, что MTA не смог открыть обычный журнал — а сообщить об этом ему всё равно надо. Значит сообщение должно попасть туда, где не зависит от правильности конфигурации.

Читают его первым при двух событиях: сразу после установки и сразу после правки конфигурации. Руководство прямо называет эти два случая типичными.

Если файла нет или в нём ничего внятного, руководство предлагает запустить MTA в отладочном режиме прямо в консоли — тогда сообщение выведется на экран, а не в файл.

⚠️ С расположением на Unix у руководства нестыковка. Раздел про отказы запуска называет файл pmta-startuperr.log, а путь к нему на Unix даёт как /var/log/pmta/log — то есть путь самого основного журнала, притом что абзацем выше файл назван отдельным. Где он лежит на самом деле, стоит проверить на узле, а не выводить из руководства.

Главная ловушка — искать причину отказа запуска в основном журнале. Его может не быть вовсе: если MTA не смог его открыть, там не появится ни строки, и пустой журнал примут за отсутствие ошибок. Смотреть надо этот файл, а при его отсутствии — запускать MTA в консоли и читать вывод.
Что делает Хаб. Этот файл не читает. Отказ запуска он видит косвенно: узел перестаёт отвечать на опрос телеметрии, и в кабинете это выглядит как недоступный узел — без причины.

Причина остаётся на узле, в этом файле. Значит при отказе запуска после применения конфигурации из Хаба идти на узел приходится руками — телеметрия скажет только, что связи нет.

Смягчает это то, что Хаб проверяет разбор конфигурации до применения и применяет её перезагрузкой, а не перезапуском: неудачная правка оставляет узел работающим на прежних настройках (config-reload).

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

Порядок разбора отказа запуска:

Шаг Что смотреть
первый этот файл — сообщение об отказе запуска
второй основной журнал, если он есть и в него успели написать
третий запуск в отладочном режиме в консоли, вывод на экран

Пустой основной журнал ничего не доказывает. Он мог не открыться вовсе — ровно тот случай, ради которого отдельный файл и существует.

Расположение проверять на месте. Руководство здесь себе противоречит, и надёжнее найти файл поиском по каталогу журналов, чем идти по указанному пути.

Порядок разбора наш. Из руководства здесь назначение файла, два типичных случая отказа запуска и предложение запустить MTA в отладочном режиме; расхождение в пути на Unix — наблюдение по тексту руководства.
Пример в конфигурации
# отказ запуска: три места по порядку
ls -l /var/log/pmta/ && cat /var/log/pmta/pmta-startuperr.logtail -n 50 /var/log/pmta/log
pmtad --debug
Выделенная строка сначала показывает, что вообще есть в каталоге журналов, — из-за нестыковки в руководстве надёжнее посмотреть, чем идти по названному пути. Нижняя выводит сообщение прямо на экран, когда файлов нет.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Считают пустой основной журнал доказательством отсутствия ошибок

§ 4.2.1

Чем чреватоОн мог не открыться вовсе — именно ради этого случая отдельный файл и существует. Пустота означает не «ошибок нет», а «писать было некуда».
Как заметитьMTA не запускается, в основном журнале ничего нового.
Как правильноЧитать файл отказов запуска, а при его отсутствии запускать MTA в отладочном режиме и смотреть вывод на экране.

Идут по пути из руководства, не найдя файла

§ 4.2.1

Чем чреватоРуководство называет файл отдельным, а путь на Unix даёт от основного журнала. Поиск по указанному пути может ничего не дать, и отсюда делают неверный вывод, что файла нет вовсе.
Как заметитьПо названному пути лежит обычный журнал, а файла отказов запуска не видно.
Как правильноСмотреть каталог журналов целиком и по времени изменения. Расположение проверять на своей установке.

Ждут причину отказа запуска от телеметрии

§ 4.2.1

Чем чреватоНе запустившийся узел перестаёт отвечать на опрос, и снаружи это выглядит как недоступность — без причины. Сообщение остаётся на узле, в файле.
Как заметитьВ кабинете узел недоступен, ошибок нет ни в одном разрезе.
Как правильноИдти на узел и читать файл. Телеметрия скажет только, что связи нет.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
Построчный текст: метка времени, а за ней ошибка запуска.
Всё здесь — из руководства, с разделом.
Наследование
Наследования у файла нет. И настройками он не управляется — в этом весь смысл: он должен работать тогда, когда конфигурация неверна. Ротация и назначение обычного журнала на него не распространяются.
Как проверить на узле
Разбор отказа запуска начинается с каталога журналов, а не с названного пути:
ls -lt /var/log/pmta/ | head
pmtad --debug
Первая покажет, какие файлы есть и какой из них менялся последним — по времени сразу видно, писал ли MTA что-то при попытке запуска. Вторая запускает его в консоли: сообщение выйдет на экран, даже если записать его некуда.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Жизненный цикл конфигурации · Подготовить узел к отправке