Перевод: Доморадов Алексей. Все права защищены. Copyright © 2007.
Примечание: При размещении данного материала у себя на сайте, просьба указывать ссылку на оригинальный сайт - www.sys-adm.org.ua.
Все замечания и предложения по переводу документации на русский язык, а также найденные ошибки и опечатки присылайте на мой электронный адрес.
Благодарности: Спасибо всем, кто помогал мне переводить эту документацию.
Особенное спасибо: Галинурову Кириллу и Грозаку Михаилу aka RedStalker_Mike.
Special thanks to: Igor Luzanov aka ISKATEL.
Этот документ описывает процесс отладки частей почтовой системы Postfix, когда они не работают так, как ожидалось. Методы отличаются от увеличения информативности лог файла, до запуска некоторых процессов демона под управлением вызова трассировщика или отладчика.
Документ предполагает, что конфигурационные файлы Postfix main.cf и master.cf располагаются в директории /etc/postfix. Вы можете использовать команду "postconf config_directory", чтобы найти действительное расположение этой директории на вашей машине.
Список методик отладки, в порядке увеличения уровня отладки, следующий:
Postfix регистрирует все неудачные и успешные доставки в лог файл. Обычно, этот файл называется /var/log/maillog или /var/log/mail; точный путь определен в файле /etc/syslog.conf.
Когда Postfix не получает или не доставляет почту, первым делом надо посмотреть ошибки, которые препятствуют Postfix работать правильно:
% egrep '(warning|error|fatal|panic):' /some/log/file | more
Примечание: наиболее важное сообщение находится вначале вывода. Сообщения об ошибках, расположенные далее, менее полезны.
Характер каждой проблемы обозначается следующим образом:
"panic" указывает, что проблема непосредственно в ПО и ее может исправить только программист. Postfix не сможет работать, пока не будет исправлена данная ошибка.
"fatal" является результатом отсутствующих файлов, неправильных разрешений, неправильных параметров настройки конфигурационного файла, которые вы можете исправить. Postfix не сможет работать, пока не будет исправлена данная ошибка.
"error" сообщает исправимое или не исправимое ошибочное состояние. Postfix не сможет работать, пока не будет исправлена данная ошибка.
"warning" указывает на некритические ошибки. Это ошибки, которые вы не в состоянии исправить (например, неисправный DNS сервер, где-то в сети), но также могут указывать локальные ошибки конфигурации, которые могут стать проблемой позже.
Начиная с версии Postfix 2.1 и более поздние, вы можете использовать Postfix для получения отладочных версий отчетов доставки почты. Эти отчеты показывают не только адреса отправителя/получателя после переписывания адреса и применения псевдонимов или пересылки (forwarding), они также показывают информацию о доставке в mailbox, доставке для не-Postfix команды, ответы от удаленных SMTP серверов, и так далее.
Postfix может производить два типа отчетов о доставке почты для отладки:
Что-если: сообщает, что случилось бы, но не доставляет почту на самом деле. Этот режим работы запрашивается с помощью:
% /usr/sbin/sendmail -bv address... Mail Delivery Status Report will be mailed to <your login name>. Отчет состояния доставки почты будет направлен на <your login name>.
Что случилось: доставляет почту и сообщает о успешных и/или неудачных доставках, включая ответы от удаленных SMTP серверов. Этот режим работы запрашивается с помощью:
% /usr/sbin/sendmail -v address... Mail Delivery Status Report will be mailed to <your login name>.
Эти отчеты содержат информацию сгенерированную, агентами доставки Postfix. Так как это запускает процессы демоны и не взаимодействует непосредственно с пользователями, результат посылается в виде почты, отправителю тестового сообщения. Формат этих отчетов фактически идентичен обычному уведомлению о недоставки.
Для детального примера отчета состояния доставки почты смотрите раздел debugging в конце документа ADDRESS_REWRITING_README.
Общей ошибкой является включение chroot режима в файле master.cf без выполнения всех необходимых шагов настройки chroot окружения. Это вызывает сбой процессов демона Postfix из-за отсутствия различных файлов.
Пример ниже показывает SMTP сервер, настроенный с выключенным chroot режимом:
/etc/postfix/master.cf:
# =============================================================
# service type private unpriv chroot wakeup maxproc command
# (yes) (yes) (yes) (never) (100)
# =============================================================
smtp inet n - n - - smtpd
Просмотрите файл master.cf на наличие любых процессов, у которых не выключен chroot режим. Если вы найдете любой процесс, сохраните копию файла master.cf и внесите соответствующие изменения. После выполнения команды "postfix reload", проверьте, исчезла ли проблема.
Если выключение chroot режима решает проблему, то поздравляем вас. Запуск Postfix в такой конфигурации, приемлемо для большинства сайтов. Если вы предпочитаете chroot режим, посмотрите файл Postfix BASIC_CONFIGURATION_README, насчет информации, как подготовить Postfix для chroot режима.
В файле /etc/postfix/main.cf, в параметре debug_peer_list, перечислите список удаленных имен сайтов или адреса. Например, чтобы увеличить информативность ПО в логах демона syslog, для соединений от или с loopback интерфейса:
/etc/postfix/main.cf:
debug_peer_list = 127.0.0.1
Вы можете указать один и более хостов, доменов, адресов или сетей/масок. Чтобы изменения вступили в силу немедленно, выполните команду "postfix reload".
Этот пример использует tcpdump. Чтобы записать сеанс связи, вам необходимо указать достаточно большой буфер с помощью опции "-s" или иначе вы потеряете некоторое или все содержимое пакетов.
# tcpdump -w /file/name -s 2000 host example.com and port 25
Запустите на некоторое время, затем остановите с помощью Ctrl-C. Для просмотра данных, используйте средство просмотра бинарных данных, ethereal или используйте мою утилиту tcpdumpx, которая доступна на ftp://ftp.porcupine.org/pub/debugging/.
Добавьте одну или более опций "-v" к выбранному определению демона в файле /etc/postfix/master.cf и выполните команду "postfix reload". Это заставит демон syslog регистрировать больше событий. Например:
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -v
Это сделает SMTP сервер Postfix более информативным. Для диагностики проблемы с перезаписью адресов укажите опцию "-v" для демона cleanup(8) и/или trivial-rewrite(8), а для диагностирования проблем с доставкой почты укажите опцию "-v" для менеджера очереди qmgr(8) или oqmgr(8) или для агента доставки lmtp(8), local(8), pipe(8), smtp(8) или virtual(8).
Многие системы позволяют вам наблюдать за запущенными процессами с помощью системного вызова трассировщика. Например:
# trace -p process-id (SunOS 4) # strace -p process-id (Linux и многие другие) # truss -p process-id (Solaris, FreeBSD) # ktrace -p process-id (generic 4.4BSD)
Еще более информативная - трассировка вызовов системной библиотеки. Примеры:
# ltrace -p process-id (Linux, также перенесена на FreeBSD и BSD/OS) # sotruss -p process-id (Solaris)
Для подробностей смотрите вашу системную документацию.
Трассировка исполняемого процесса может дать полезную информацию о том, что процесс пытается сделать. Здесь приведены сведения, которые вы можете получить без запуска интерактивного отладчика, как описано в следующем разделе.
Postfix может присоединить трасировщик вызовов всякий раз, когда стартует процесс демон. Бывает несколько типов трасировщиков.
Трассировщики системных вызовов, такие как trace, truss, strace или ktrace. Они показывают взаимодействие между процессом и ядром.
Трассировщики библиотечных вызовов, такие как sotruss и ltrace. Они показывают вызовы библиотечных функций и дают лучшее представление о том, что происходит в пределах процесса.
Добавьте опцию -D к команде, вызывающей подозрения, в файле /etc/postfix/master.cf, например:
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -D
Отредактируйте определение debugger_command в файле /etc/postfix/main.cf так, чтобы он вызывал трассировщик вызова на ваш выбор, например:
/etc/postfix/main.cf:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin;
(truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5
Выполните команду "postfix reload" и наблюдайте за лог файлом.
Если у вас есть установленный X Windows на машине с Postfix, тогда может быть использован интерактивный отладчик такой, как xxgdb.
Отредактируйте определение debugger_command в файле /etc/postfix/main.cf так, чтобы вызывался xxgdb:
/etc/postfix/main.cf:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
Убедитесь, что gdb находится в пути поиска команды и экспортируйте XAUTHORITY для обеспечения контроля доступа X системы, например:
% setenv XAUTHORITY ~/.Xauthority (csh syntax) $ export XAUTHORITY=$HOME/.Xauthority (sh syntax)
Добавьте опцию -D к определению демона в файле /etc/postfix/master.cf, например:
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -D
Остановите и запустите Postfix. Это необходимо для того, чтобы Postfix запустился с соответствующими параметрами XAUTHORITY и DISPLAY.
Когда ожидаемый процесс демон стартует, появится окно отладчика, и вы сможете наблюдать в деталях за тем, что происходит.
Если у вас нет установленной X Windows на машине с Postfix или вы незнакомы с интерактивными отладчиками, тогда вы можете попробовать запустить gdb в не интерактивном режиме и иметь возможность распечатать трассировку стека при аварийном завершении процесса.
Отредактируйте определение debugger_command в файле /etc/postfix/main.cf так, чтобы вызывался отладчик gdb:
/etc/postfix/main.cf:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo
where; sleep 8640000) | gdb $daemon_directory/$process_name
$process_id 2>&1
>$config_directory/$process_name.$process_id.log & sleep 5
Добавьте опцию -D к определению демона в файле /etc/postfix/master.cf, например:
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -D
Выполните команду "postfix reload" для вступления изменений в силу.
Всякий раз, когда запущен процесс демон, будет создан выходной файл, названный именем демона и ID процесса (например, smtpd.12345.log). При аварийном завершении процесса, трассировка стека (с выводом от команды "where") будет записана в лог файл.
Иногда поведение Postfix просто не соответствует исходному коду. Почему программа может отклоняться от инструкций, данных ее автором? Существует две возможности.
Компилятор допустил ошибку. Это случается редко.
Ошибка аппаратной части. Есть ли у машины память с ECC?
В обоих случаях, исполняемая программа - это не программа, которая должна была выполняться, так что может случиться что угодно.
Существует третья возможность:
Ошибки в системном ПО (ядре или библиотеках).
Сбои связанные с аппаратной частью обычно не воспроизводятся таким же путем после выключения питания и перезагрузки системы. Postfix мало может помочь в случае плохого аппаратного обеспечения. Убедитесь, что используете аппаратное обеспечение, которое, по крайней мере, может обнаружить ошибки памяти. В противном случае Postfix будет просто ждать сбоя от маленькой ошибки. Критические системы заслуживают "настоящего" аппаратного обеспечения.
Когда компилятор допускает ошибку, проблема может быть воспроизведена всякий раз, когда будет запущена скомпилированная программа. Наиболее часто ошибки компилятора случаются в оптимизаторе кода. Если проблема воспроизводима между выключением питания и перезагрузкой системы, стоит пересобрать Postfix с отключенной оптимизацией, и посмотреть сделала ли оптимизация различие.
Чтобы собрать Postfix с выключенной оптимизацией:
% make tidy % make makefiles OPT=
Это приводит к созданию набора Makefile'ов, не запрашивающих оптимизацию со стороны компилятора.
Как только созданы makefile'ы, соберите ПО:
% make % su Password: # make install
Если проблема разрастается, тогда время попросить помощь у вашего поставщика.
Люди, участвующие в списке рассылки postfix-users@postfix.org очень полезны, особенно если ВЫ предоставляете им достаточно информации. Запомните, эти добровольцы желают помочь вам, но у них мало времени.
Когда вы сообщаете о проблеме, убедитесь, что включили следующую информацию:
Суть самой проблемы. Пожайлуста не посылайте некоторый лог файл без объяснения того, что вы считаете ошибкой в нем.
Полные сообщения об ошибках. Пожайлуста используйте т.н. метод скопировать-и-вставить или используйте вложения, вместо того, чтобы рассказывать информацию по памяти.
Лог файл Postfix. Смотрите текст вначале документа DEBUG_README, чтобы узнать, где хранится лог файл. Пожайлуста не расстраивайте людей помогающих вам "сворачиванием" строк записей лог файла.
Рассмотрите использование тестового email адреса для того, чтобы не показывать email адреса или пароли невинных людей.
Если вы не можете использовать тестовый email адресс, пожайлуста скройте информацию последовательно. Замените каждую букву с помощью символа "A", а каждую цифру с помощью символа "D", чтобы люди помогающие вам, могли распознать синтаксические ошибки.
Вывод команды "postconf -n". Пожайлуста не посылайте ваш main.cf файл или 400+ строк вывода команды postconf.
Лучше предоставьте вывод утилиты postfinger. Которая может быть найдена на http://ftp.wl0.org/SOURCES/postfinger.
Если проблема связана с SASL, включите в отчет вывод утилиты saslfinger. Которая может быть найдена на http://postfix.state-of-mind.de/patrick.koetter/saslfinger/.
Если проблема связана с большим количеством почты в очереди, включите в отчет вывод утилиты qshape, как описано в файле QSHAPE_README.
Если проблема связана с протоколом (прерывание соединения или SMTP сервер сообщает о синтаксических ошибках и т.д.) включите в отчет запись SMTP сессии с помощью tcpdump, как описано в документе DEBUG_README.
| Дата последнего обновления: 30.10.2008. | Postfix version: 2.3.4. |