Читать онлайн «Ubuntu 10. Краткое руководство пользователя». Страница 36

Оператор if в bash работает аналогично оператору if в других языках программирования. Если истинно первое условие, то выполняется первый список команд, иначе — проверяется второе условие и т. д. Количество блоков elif, понятно, не ограничено.

Самая ответственная задача — это правильно составить условие. Условия записываются в квадратных скобках. Вот пример записи условий:

# переменная N = 10

[N==10]

# переменная N не равна 10

[N!=10]

Операции сравнения указываются не с помощью привычных знаков > или <, а с помощью следующих выражений:

□ — lt — меньше;

□ — gt — больше;

□ — le — меньше или равно;

□ — ge — больше или равно;

□ — eq — равно (используется вместо ==).

Применять данные выражения нужно следующим образом:

[переменная выражение значение | переменная]

Например:

# N меньше 10

[$N — lt 10]

# N меньше A

[$N — lt $A]

В квадратных скобках вы также можете задать выражения для проверки существования файла и каталога:

□ — e файл — условие истинно, если файл существует;

□ — d каталог — условие истинно, если каталог существует;

□ — x файл — условие истинно, если файл является исполнимым.

С оператором case мы уже немного знакомы, но сейчас рассмотрим его синтаксис подробнее:

case переменная in

значение_1) команды_1;;

…

значение_^ команды_N;;

*) команды_по_умолчанию;;

esac

Значение указанной переменной по очереди сравнивается с приведенными значениями (значение_1…, значение_N). Если есть совпадение, то будут выполнены команды, соответствующие значению. Если совпадений нет, то будут выполнены команды по умолчанию. Пример использования case был приведен в листинге 22.3.

Всему есть своя причина — сбой не происходит сам по себе. Причиной может стать либо ошибка программного обеспечения, либо отказ «железа». Исходя из этого, различают программные и аппаратные сбои. Последние можно смело назвать аппаратно-программными, поскольку из-за отказа аппаратуры довольно часто происходят программные сбои. Самый простой пример — отказ винчестера, вследствие которого программа не может записать или прочитать данные, и происходит программный сбой. При некорректной работе оперативной памяти происходят порой сложнообъяснимые ошибки программного обеспечения.

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

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

Когда причина ошибки в ваших действиях — это самый простой случай. Иногда бывает так, что система работала-работала, а на следующий день половина служб не запускается. В чем же причина? Тут вам поможет только чтение журналов системы, находящихся в каталоге /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.

Причиной аппаратного сбоя, как мы знаем, может стать или полный отказ устройства, или частичный отказ одного из его модулей, что свидетельствует о необходимости замены всего устройства. При полном отказе устройства результат виден невооруженным взглядом. Наиболее часто отказывают жесткие диски и оптические приводы (поскольку в их конструкции есть движущиеся механические детали), на втором месте — оперативная память, далее — видеокарты и прочие карты расширения. Самыми надежными остаются процессор и материнская плата. Хотя все относительно и определяется качеством устройства, которое напрямую зависит от производителя «железа». Не секрет, что вероятность отказа у «чистокровных» компьютеров от Intel и HP намного меньше, чем у собранного в подвале неизвестной компьютерной фирмой из тайваньских комплектующих.

Да, так я и думал до того, как у меня появился «чистокровный» HP 6735s, у которого спустя полгода после покупки отказал правый динамик. В сервис я его так и не отнес, потому что ноутбук нужен каждый день, но где же хваленое качество HP?

Причина отказа жесткого диска кроется в ненадежной электронике или некачественном носителе (магнитных дисках, на которых, собственно, и хранится информация). На самом деле, что конкретно в винчестере вышло из строя, — не так важно, все равно придется покупать новый, ведь неисправные практически не поддаются ремонту, особенно в кустарных условиях. Иногда можно еще восстановить информацию, но это нужно делать в лабораториях, оснащенных специальным оборудованием. Фирм, занимающихся восстановлением информации с винчестеров, немного, а их услуги стоят довольно дорого, поэтому, чтобы не пришлось платить двойную плату (за новый жесткий диск и за восстановление информации со старого), периодически делайте резервные копии. Для этого просто записывайте важные для вас данные на CD или DVD, а еще лучше — на внешние винчестеры USB (последние пока дорогие, но они и наболее удобные). Потом резервные копии лучше всего хранить в безопасном месте, скажем, в сейфе, если он есть.

Жесткий диск может портиться постепенно. Как правило, предшественниками полного отказа становятся «битые» блоки, что проявляется блокированием записи или чтения данных. Если система не может прочитать информацию из такого сектора, вы увидите на консоли соответствующее сообщение. Если вы подозреваете, что причина именно в наличии «битых» секторов, проверьте ваш жесткий диск с помощью программы badblocks. Если ваши опасения подтвердились, немедленно сделайте резервную копию всех данных, которые еще можно прочитать с диска, поскольку сейчас ваш жесткий диск непредсказуем, — он может еще проработать с полгода или год, а может отказать уже завтра или даже через час. После этого купите новый жесткий диск (именно новый, а не другой б/у) и восстановите информацию с резервной копии, а старый винчестер постарайтесь продать, пока он еще работает.