Денис Колисниченко Ubuntu 10. Краткое руководство пользователя
  • Register

23.2. Программный сбой

23.2. Программный сбой

Прежде всего, нужно выяснить и по возможности устранить причину сбоя. Если это сугубо программный сбой, то причины две: неправильная настройка программы (или системы) и ошибка программы.

23.2.1. Неправильная настройка программы или системы

Как работала система до сбоя? Встречался ли подобный сбой раньше? Если ничего такого ранее вы не наблюдали и система работала как швейцарские часики, значит, скорее всего, причина в неправильной ее настройке. Вспомните, какие файлы конфигурации вы изменяли (или какие параметры устанавливали с помощью графических конфигураторов). Просто по памяти восстановите исходные значения и перезапустите сервис или службу, ставшую причиной сбоя, — возможно, проблема решится. Рекомендуется перед каким-либо изменением, вносимым в файл конфигурации системы, делать его резервную копию. Потом вам же будет проще восстановить исходные значения. Можно рекомендовать и другой подход — закомментировать прежние директивы/значения файла конфигурации, а новые писать под ними. В случае вашей ошибки вы всегда сможете восстановить исходные значения.

23.2.2. Ошибка программы. Журналы системы

Когда причина ошибки в ваших действиях — это самый простой случай. Иногда бывает так, что система работала-работала, а на следующий день половина служб не запускается. В чем же причина? Тут вам поможет только чтение журналов системы, находящихся в каталоге /var/log:

? /apache2/ — журналы Web-сервера Apache2;

? /apt/ — журналы системы установки пакетов APT;

? /clamav/ — журналы антивируса ClamAV;

? /cups/ — журналы системы печати;

? /gdm/ — журналы менеджера дисплея;

? /installer/ — журналы программы установки;

? /news/ — журналы NNTP-сервера и NNTP-клиентов;

? /proftpd/ — журналы FTP-сервера;

? /samba/ — протоколы Samba;

? auth.log — журналы аутентификации (кто и когда входил в систему);

? daemon.log — журналы для разных демонов (служб);

? dmesg — загрузочные сообщения ядра;

? dpkg.log — журналы программы dpkg;

? kern.log — журналы сообщений ядра;

? mail* — журналы почтовой службы;

? messages — различные сообщения ядра (и в некоторых случаях — обычных программ);

? mysql.log — протокол MySQL-сервера;

? secure — журнал службы безопасности;

? syslog — журнал демона syslog;

? Xorg.0.log — журнал системы XFree86 (дисплей 0);

? user.log — различные сообщения программ пользовательского уровня.

Протоколирование сообщений системы и программ ранее выполнялось двумя демонами: klogd и syslogd. В современных дистрибутивах (Ubuntu — не исключение) используется всего один демон протоколирования — rsyslogd.

Имена файлов журналов могут немного отличаться от перечисленных здесь, поскольку они зависят от настроек системы, в том числе и от настроек демона rsyslogd. Кроме того, в системе могут создаваться дополнительные файлы протоколов или даже каталоги, содержащие файлы протоколов, — повторюсь, все зависит от настроек системы. Чтобы узнать, какие файлы протоколов имеются в вашей системе, какие из них являются основными и для чего используются, откройте и изучите файлы конфигурации rsyslogd: /etc/rsyslog.conf и /etc/rsyslog.d/50-default.conf.

Однако в файлах конфигурации демона rsyslogd перечислены далеко не все файлы протоколов. Многие серверы ведут свои журналы, имена файлов которых вы можете узнать в файлах конфигурации того или иного сервера. Так, сообщения различных программ пользовательского уровня, т. е. обычных программ, возможно, запущенных с привилегиями root, протоколируются в файле /var/log/user.log.

В каком же журнале искать ошибку? Тут нужно исходить из принципа взаимоисключения: если у вас не работает Web-сервер Apache, то искать причину нужно в каталоге /var/log/apache2/, но никак не в файле /var/log/user.log.

На http://hostingrust.ru хостинг dayz.

Форма входа

Советы