Устранение неполадок в системных ресурсах и в конфигурации окружения
В учебнике на тему 202 подробнее рассказывалось, что запуск Linux после загрузки ядра управляется процессом init. Основная конфигурация init лежит в /etc/inittab. Этот файл /etc/inittab содержит подробности того, какие шаги следует произвести на каждом уровне запуска. Но, возможно, наиболее решающим является тот факт, что там задается уровень запуска для последующих действий. Если система имеет проблемы во время загрузки, установка другого уровня запуска может помочь. Ключевой строкой будет что-нибудь вроде этого:
# The default runlevel. (in /etc/inittab)
id:2:initdefault:
Сценарии инициализации ("rc-скрипты") запускаются во время загрузки, завершения, и всегда, когда система меняет уровни запуска, и они ответственны за запуск и остановку большинства системных демонов. В большей части (читай в современных) дистрибутивах Linux, они находятся в каталоге /etc/init.d/ и ссылаются на каталоги /etc/rc<N>.d/ (при N=уровень запуска), где они имеют имена "S*" для сценариев запуска и "K*" для сценариев завершения. Система никогда не запускает сценариев из каталога /etc/init.d, а ищет их в /etc/rc<N>.d/[SK]*.
Иногда, но бывет так, что системный администратор желает изменить общий для всей системы сценарий запуска оболочки /etc/profile. Эта смена влияет на всякую интерактивную оболочку (за исключением пользователей /bin/tcsh и других не-/bin/sh-совместимых оболочек). Повреждение этого файла может с легкостью привести к ситуации, когда никто не сможет зайти в систему, и для исправления потребуется диск восстановления. Обычный способ изменения поведения оболочки на индивидуальной основе состоит в изменении /home/$USER/.bash_profile и /home/$USER/.bashrc.
Система sysctl (см. man-страницу для sysctl) была взята из BSD UNIX® и используется для настройки некоторых системных ресурсов. Выполните sysctl -a, чтобы увидеть, какие переменные могут управляться sysctl, и какие значения они принимают. Утилита sysctl наиболее полезна при настройке как параметров сети, так и некоторых параметров ядра. Файл /etc/sysctl.conf используется, чтобы задать параметры sysctl во время загрузки.
В большинстве систем, динамические библиотеки постоянно добавляются, обновляются, заменяются и удаляются. Поскольку в системе почти каждой программе требуется найти и загрузить динамическую библиотеку, имена, номера версий, и местоположение большинства динамических библиотек кэшируются программой ldconfig. Обычно кэшируются динамические библиотеки из системных каталогов /lib/ и /usr/lib/. Чтобы добавить больше каталогов к глобальному списку каталогов для поиска по умолчанию, следует добавить имена этих каталогов (например /usr/X11R6/lib) в файл /etc/ld.so.conf и запустить ldconfig под root.
Тема 211 подробно рассматривает syslog. Основной файл, про который следует вспомнить, если у вас появились проблемы (или если вы хотите убедиться, что вы сможете проанализировать их позже) -- это /etc/syslog.conf. Изменяя содержимое этой конфигурации, у вас есть детальнейший контроль над тем, какие события журналируются, и куда пишутся файлы журнала, возможно даже включая почту и удаленные машины. Если появляется проблемы, убедитесь, что подсистемы, где, по вашему мнению, они возникают, журналируют информацию в таком стиле, чтобы вы смогли быстро проверить.
Почти на каждой системе Linux запущен демон cron. За подробностями о работе cron и crontab обратитесь к теме 213. Вообще говоря, следует помнить, что источником потенциальной проблемы могут стать сценарии, выполняющиеся с временными интервалами. Возможно то, что, по вашему мнению, является проблемой ядра или приложения, происходит от не связанных с ними сценариев, которые запускает cron за вашей спиной.
Экстремальный метод состоит в полном прекращении работы cron. Номер его процесса может быть найден с помощью ps ax | grep cron, а kill может его прекратить. Менее крутая мера состоит в редактировании /etc/crontab, чтобы выполнялся более традиционный набор задач; также, отредактировав /etc/cron.allow и /etc/cron.deny, убедитесь, что запланированные задачи пользователей отменены. Хотя пользователи и не имеют достаточных прав, чтобы вызвать проблемы для всей системы, по-хорошему, первым шагом стоит временно заблокировать пользовательскую конфигурацию crontab и посмотреть, разрешило ли это ваши проблемы.
