IBM®
Перейти к тексту
    в России и странах СНГ [изменить]    Условия использования
 
 
   
    Главная страница    Продукты    Услуги и решения    Поддержка и загрузка    Мой профиль    
Перейти к тексту

developerWorks Россия  >  Linux  >

Подготовка к экзамену LPI 201: Устранение неполадок

Средний уровень администрирования (LPIC-2) тема 214

developerWorks
На предыдущую страницуСтраница 6 из 9 На предыдущую страницу

Опции документа

Обсудить


Выскажите мнение об этом учебном пособии

Помогите нам улучшить содержание


Устранение неполадок в системных ресурсах и в конфигурации окружения

The initialization

В учебнике на тему 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 и посмотреть, разрешило ли это ваши проблемы.



В начало



На предыдущую страницуСтраница 6 из 9 На предыдущую страницу
    IBM в России Конфиденциальность Контакты