Бывает, что какое-либо письмо не проходит и в логах видно что-то странное, причем методы диагностики без включения полных логов не помогают. Тогда приходится делать так:
# /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
#1 by SH on 17.02.2010 - 20:51
Quote
Проще сначала прогнать тестовый SMTP диалог с использованием exim -bhc 192.168.1.1. Адрес естественно, реальный добавить. А то гроханье живого exima пахнет экстримизмом. Это IMHO.
#2 by jared on 17.02.2010 - 22:15
Quote
Тут случай другой был, SMTP-диалогом проблема не решалась. А гроханье можно сделать и через правку стартового скрипта с дописыванием -d+all, так вообще шансов почти нет, что кто-то заметит рестарт.
#3 by skeletor on 29.09.2010 - 08:41
Quote
На самом деле в момент отладки очень удобно (на взирая на то, что нужно убивать и запускать exim), так как в логе подробно раскрываются все запросы к БД. Благодаря этому, я понял, какое значение берёт exim и с чем сравнивает.
Вообщем совет на 5!