Введение

Troubleshooting: Это небольшой список решений для проблем, наиболее часто возникающих в ходе установки. Это не исчерпывающая информация, но вы можете начать поиск решения граблей отсюда. Такая запутанная настройка и инсталляция как в этом документе, может привести к тому что некоторые компоненты будут работать неправильно. Вообще советую сделать несколько следующих шагов. Запустите систему в базовой конфигурации, добавляя компонент за компонентом, чтобы выяснить какой из них сбоит.

Шаг 1: Проверьте ваши файлы конфигурации.

Опечатки — главный враг, особенно когда идет речь о системе авторизации. Проверьте ваши конфигурационные файлы и базу данных на предмет опечаток. Если вы делаете изменения настроек для сервиса, убедитесь, что вы перезапустили сервиса, дабы изменения вступили в силу.

Листинг 15.1:

# /etc/init.d/service restart

Шаг 2: Все необходимые сервисы запущены и работают?

Если не запущены, запустите. Крайне сложно отлаживать программу если она не запущена. Иногда сервис запускается, но не функционирует. Иногда, когда используется неправильный файл конфигурации сервис может использовать другой порт предназначенный другому процессу. Иногда вы можете воспользоваться netstat. Или если возможно , перезагрузите ваш сервер, это очистит любой зависший сервис.

Листинг 15.2:

# /etc/init.d/$service status

# netstat -a | grep $service (или $port)

Шаг 3: Все сервисы используют правильные файлы конфигурации?

Если вы внесли изменения в конфигурационные файлы сервиса, убедитесь что он использует новые параметры. Некоторые программы, вроде postfix могут показывать конфигурацию их параметров.

Листинг 15.3:

# apachectl fullstatus  (необходим lynx)

# apachectl configtest (проверка нормальной конфигурации)

# postconf -n (показывает текущие параметры используемые postfix)

# /etc/init.d/$service restart

Шаг 4: Проверьте логи.

На то логи и существуют, чтобы помочь нам выяснить причину, а иногда и подсказать решение проблемы. Просмотрите все логи, которые имеют отношение к программе, ее сбою.

Листинг 15.4:

# kill -USR1 `ps -C metalog -o pid=`(для выключения metalog buffering)

# nano -w /var/log/mail/current

# cat /var/log/mysql/mysql.log

# tail /var/log/apache/error_log

Вы также можете найти параметр debug_peer в main.cf который может быть полезен. Включение этого параметра, увеличит подробность выводящихся сообщений в логи.

Листинг 15.5: добавление поддержки debug_peer

# nano -w /etc/postfix/main.cf

debug_peer_level = 5

debug_peer_list = $host.domain.name

(раскомментируйте одну из нужных строк)

Шаг 5: Попробуйте связаться с сервисом.

SMTP, IMAP, и POP3 отвечают на telnet сессию, как вы видели немного раньше при конфигурации postfix. Иногда помогает открыть telnet сессию с сервисом, для того чтобы выяснить что случилось.

Листинг 15.6:

# telnet localhost $port

(SMTP на 25-м, IMAP, на 143-м, POP3 на 110-м порту. по крайней мере вы

должны увидеть слово ОК. Так вы будете знать что сервис запущен, и готов к ответу.)

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

* OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc.

Шаг 6: Иногда только большая пушка может дать нам информацию: strace.

Вы должны иметь эту программу всегда под рукой. Это бесценный инструмент для отлаживания программ. Вы можете запустить из командной строки starce и наблюдать все системные вызовы происходящие в программе. Часто дамп содержит огромное количество информации, так что вы можете либо наблюдать в реальном времени, за транзакцией приводящей к краху программы, или записать его в файл, для неторопливого просмотра позже.

Листинг 15.7:

# emerge strace

# strace $command

# strace -p `ps -C $service -o pid=`