Ищем ошибки в работе exim

Бывает, что какое-либо письмо не проходит и в логах видно что-то странное, причем методы диагностики без включения полных логов не помогают. Тогда  приходится делать так:

# /usr/local/etc/rc.d/exim stop
# exim -bd -d+all > /var/log/exim-debug.log 2>&1

Здесь мы потушили Exim и пустили его в ручном режиме с выводом полной информации о его работе (-d+all). Неприятная особенность заключается в том, что Exim пишет лог своей работы в stderr, с которым довольно неудобно работать. Потому конструкция «> /var/log/exim-debug.log 2>&1» перенаправляет stderr в файл /var/log/exim-debug.log.

Все, теперь можно ждать копии проблемного письма, другие пользователи при этом продолжат спокойно работать. После того, как собрали нужное для устранения ошибки количество информации, останавливаем ручной режим нажатием Ctrl-C и запускаем Exim в нормальном режиме работы:

# /usr/local/etc/rc.d/exim start

Вам также может понравиться

Об авторе jared

3 комментария

  1. Проще сначала прогнать тестовый SMTP диалог с использованием exim -bhc 192.168.1.1. Адрес естественно, реальный добавить. А то гроханье живого exima пахнет экстримизмом. Это IMHO.

  2. Тут случай другой был, SMTP-диалогом проблема не решалась. А гроханье можно сделать и через правку стартового скрипта с дописыванием -d+all, так вообще шансов почти нет, что кто-то заметит рестарт.

  3. На самом деле в момент отладки очень удобно (на взирая на то, что нужно убивать и запускать exim), так как в логе подробно раскрываются все запросы к БД. Благодаря этому, я понял, какое значение берёт exim и с чем сравнивает.
    Вообщем совет на 5!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *