Запуск и останов системы
Last updated
Last updated
Как и практически все операции в UNIX, процедуры включения/выключения системы превратились в тщательно спроектированные процессы, которые учитывают множество возможных непредвиденных ситуаций. Как администраторы мы рассматриваем сложности процесса загрузки во многих аспектах, чтобы предотвратить потенциальные проблемы и устранить возникшие.
Процесс начальной загрузки системы всегда был достаточно сложным, но все же он был несколько проще в те дни, когда изготовители определяли буквально все аспекты аппаратного и программного обеспечения. Теперь, когда операционные системы управляют аппаратным обеспечением персональных компьютеров, процедура загрузки должна выполняться по их правилам. При этом приходится иметь дело с множеством возможных конфигураций. При чем, рассматриваемые этапы загрузки могут отличаться от системы к системе.
Под начальной загрузкой (bootstrapping), понимается запуск системы при включении питания. Поскольку обычные средства операционной системы на данном этапе еще недоступны, система должна “самозагрузиться”, выполнить POST (Power on Self-Test). В ходе этого процесса ядро системы загружается в память и активизируется. Затем выполняется ряд инициализационных задач, после чего система готова к обслуживанию пользователей.
Начальная загрузка — это период особой уязвимости системы. Ошибки в конфигурации, сбои в работе или отсутствие нужного оборудования, повреждения файловых систем могут помешать компьютеру нормально начать работу. Настройка режимов загрузки часто является одной из первых задач, которую приходится решать администратору в новой системе, особенно при добавлении нового оборудования. К несчастью, эта задача — одна из наиболее сложных, и для ее решения необходимо хорошо знать многие другие аспекты системы.
Когда включается питание, запускается на выполнение загрузочный код, хранящийся на постоянном запоминающем устройстве. Он должен запустить ядро. Ядро опрашивает состояние аппаратных устройств, а затем запускает демон init, идентификатор которого всегда равен 1.
Прежде чем система полностью загрузится, должны быть проверены и смонтированы файловые системы и запущены системные демоны. Соответствующие процедуры реализуются с помощью сценариев интерпретатора команд, которые последовательно запускаются демоном init. Конкретная структура сценариев и способ их выполнения зависят от системы.
При нормальной работе системы сами выполняют начальную загрузку в автономном режиме, после чего к ним могут получить удаленный доступ администраторы и пользователи. Однако администраторам необходимо иметь инструмент восстановления системы в случае, если неожиданный отказ дисковода или какая-нибудь проблема конфигурации помешает системе нормально выполнить процесс начальной загрузки. Системы UNIX (вместо загрузки “по полной программе”) могут ограничиться только самым необходимым, а именно активизацией командной оболочки на системной консоли. Этот вариант называют входом системы в так называемый “однопользовательский режим”, режим восстановления или профилактический режим — все эти термины в рамках изучаемого материала взаимозаменяемы. Однопользовательский режим не позволяет выполнять сетевые операции, а для использования системной консоли вам нужно иметь физический доступ к ней.
В большинстве систем для входа в однопользовательский режим во время начальной загрузки необходимо передать ядру в командной строке определенный параметр. Если система уже загружена и работает, вы можете перевести ее в однопользовательский режим с помощью команды shutdown или telinit.
Типичная процедура начальной загрузки состоит из шести отдельных этапов:
считывание начального загрузчика с главной загрузочной записи;
загрузка и инициализация ядра;
обнаружение и конфигурирование устройств;
создание процессов ядра;
вмешательство администратора (только в однопользовательском режиме);
выполнение системных сценариев запуска.
Почти все этапы не требуют интерактивного контроля со стороны администратора. Ведь администраторы имеют возможность управлять загрузкой системы, редактируя файлы конфигурации для сценариев запуска системы или изменяя аргументы, передаваемые загрузчиком ядру.
ИНИЦИАЛИЗАЦИЯ ЯДРА
Ядро представляет собой программу, и в качестве первой задачи начальной загрузки выполняется запись этой программы в память для последующего выполнения. Имя файлу ядра дает его изготовитель, но по традиции оно называется /unix или /vmunix. В Linux-системах ядро обычно получает путевое имя в виде вариации на тему /boot/vmlinuz.
В большинстве систем загрузка осуществляется в два этапа. Сначала в память компьютера с диска считывается (с помощью кода, записанного на постоянном запоминающем устройстве) небольшая программа начальной загрузки (именуемая начальным загрузчиком), которая затем выполняет собственно загрузку ядра. Эта процедура совершается вне UNIX-домена и поэтому не стандартизирована среди систем.
Ядро выполняет тесты, позволяющие определить, сколько памяти имеется в распоряжении системы. Часть внутренних структур ядра имеет фиксированный размер, поэтому ядро резервирует определенный объем физической памяти для самого себя. Эта память недоступна пользовательским процессам. Ядро выдает на консоль сообщение об общем объеме физической памяти и объеме памяти, доступной пользовательским процессам.
Одна из первых задач ядра — исследование компонентов аппаратного обеспечения. В процессе тестирования различных системных шин и инвентаризации оборудования ядро выводит на консоль краткую информацию о каждом обнаруженном устройстве. Во многих случаях ядро загружает драйверы устройств как независимые модули ядра. Для систем, ориентированных на персональные компьютеры, дистрибутивы включают ядро, которое способно работать в большинстве аппаратных конфигураций компьютеров, требуя при этом минимальной настройки или же вообще обходясь без нее.
Процесс конфигурации аппаратного обеспечения должен быть относительно прозрачным для администраторов, особенно в среде Linux. Готовые ядра имеют модульную структуру и автоматически обнаруживают большую часть устройств. Тем не менее вы можете встретить нераспознанные устройства. В таком случае, вам придется выполнить конфигурацию драйверов вручную.
После завершения этапа базовой инициализации ядро создает в области памяти, выделенной для пользовательских программ, несколько “самовыполняющихся” процессов. Это происходит “в обход” стандартного системного механизма fork.
Количество таких процессов зависит от операционной системы, хотя демон init всегда имеет идентификатор процесса (PID), равный 1. Большинство систем UNIX использует sched в качестве процесса с идентификатором 0.
В Linux процесс с идентификатором PID, равным 0, отсутствует. Демон init работает в сопровождении с различными обработчиками памяти и сигналов ядра, в том числе с теми, которые представлены в табл. ниже. Все эти процессы имеют идентификаторы с низкими номерами, а их имена в листингах команды ps заключены в квадратные скобки (например, [kacpid]). Иногда имена процессов могут содержать в конце символ косой черты и цифру, как, например, [kblockd/0]. Число указывает процессор, на котором выполняется данный процесс. Эта информация может быть полезна при настройке многопроцессорной системы.
*Для каждой смонтированной файловой системы ext3 или ext4 существует один процесс kjournald.
Из этих процессов только init является полноценным пользовательским процессом; остальные фактически представляют собой части ядра, которые были сделаны процессами из концептуальных соображений.
Системы UNIX создают подобные процессы ядра, но поскольку эти процессы отображают особенности конкретной реализации ядра, никакие имена или функции не могут быть одинаковыми для разных систем. К счастью, администраторам никогда не приходится взаимодействовать с этими процессами напрямую.
После создания этих процессов ядро больше не принимает участия в процедуре начальной загрузки системы. К этому моменту, однако, еще не создан ни один из процессов, управляющих базовыми операциями (например, регистрацией пользователей в системе), и большинство демонов не запущено. Обо всем этом позаботится (в некоторых случаях косвенно) демон init.
Если систему нужно запустить в режиме восстановления, оператор устанавливает в командной строке специальный флаг, а ядро передает эту информацию демону init в качестве уведомления о запуске. Во время однопользовательской загрузки вы должны получить приглашение ввести пароль пользователя root. Если он введен правильно, запускается интерпретатор команд с правами суперпользователя. Можно не задавать пароль, а просто нажать комбинацию клавиш <Ctrl+D>, после чего загрузка продолжится в многопользовательском режиме.
В однопользовательском режиме команды выполняются почти так же, как и в полностью загруженной системе. Однако иногда монтируется только корневой раздел. Для того чтобы можно было использовать программы, находящиеся вне каталогов /bin, /sbin или /etc, необходимо вручную смонтировать остальные файловые системы.
Во многих однопользовательских средах корневой каталог файловой системы монтируется в режиме только для чтения (read-only). Если каталог /etc является частью корневой файловой системы (обычная ситуация), редактирование многих файлов конфигурации будет невозможно1. Чтобы выйти из положения, придется начать однопользовательский сеанс с повторного монтирования каталога / в режиме чтения/записи. Нужное действие в Linux-системах выполняет следующая команда.
# mount -о rw, remount /
В большинстве других систем вы можете выполнить команду mount /, чтобы реализовать обращение к файлу fstab или vfstab и выяснить, как должна быть смонтирована файловая система.
В системе Red Hat загрузка в однопользовательском режиме выполняется несколько активнее, нежели обычно. До того момента, когда на экран будет выведено приглашение интерпретатора команд, этот дистрибутив попытается смонтировать все локальные файловые системы. Хотя на первый взгляд такой подход кажется удобным, но при использовании недостаточно продуманной файловой системы он может порождать проблемы.
Команда fsck, которая проверяет и восстанавливает поврежденные файловые системы, обычно выполняется в ходе автоматической загрузки. Если система запускается в однопользовательском режиме, команду fsck придется вводить вручную.
Когда интерпретатор команд однопользовательского режима завершит свою работу, система продолжит загрузку в нормальном режиме.
В тот момент, когда система сможет выполнять сценарии запуска, ее уже можно назвать UNIX. Это еще не полностью загруженная система, но “загадочных” этапов процесса загрузки больше не осталось. Файлы сценариев представляют собой обычные командные файлы, которые выбираются и запускаются демоном init по сложному, но, в общем-то, понятному алгоритму.
Точное местонахождение, содержимое и организация сценариев запуска заслуживают отдельного изучения.
После выполнения сценариев инициализации система полностью готова к работе. Такие системные демоны, как DNS- и SMTP-серверы, принимают и обслуживают подключения. Не забывайте о том, что демон init продолжает играть важную роль даже по завершении начальной загрузки.
У демона init есть один однопользовательский и несколько многопользовательских «уровней выполнения», определяющих, какие ресурсы системы будут доступны пользователю. Уровни выполнения рассматриваются ниже.
До этого момента описывалась общая схема начальной загрузки. Теперь некоторые наиболее важные (и сложные) ее этапы необходимо рассмотреть подробнее, проанализировав особенности функционирования Intel-систем.
Загрузка системы на персональном компьютере — это многоступенчатый процесс. Когда включается компьютер, начинает выполняться код, записанный на постоянном запоминающем устройстве. Точное его местонахождение и структура зависят от типа оборудования. В компьютерах, созданных специально для UNIX или другой коммерческой операционной системы, код “прошивается” разработчиком, который заранее задает алгоритм подключения устройств, базовой инициализации сети и распознавания локальных файловых систем. Это очень удобно для системного администратора. Ему достаточно ввести лишь имя нового файла ядра, а код постоянного запоминающего устройства автоматически обнаружит и прочитает этот файл.
На персональных компьютерах код начальной загрузки представлен в виде базовой подсистемы ввода-вывода — BIOS (Basic Input/Output System), которая чрезвычайно упрощена в сравнении с фирменным кодом UNIX-станций. В действительности в системе BIOS есть несколько уровней кода: для самого компьютера, для видеоплаты, для SCSI-адаптера, если таковой имеется, и иногда для других периферийных устройств вроде сетевых плат.
Встроенному коду BIOS известно об устройствах, расположенных на материнской плате, в частности о IDE- и SATA-контроллерах (и жестких дисках), плате сетевого адаптера, измерителе мощности и температуры, контроллере клавиатуры, последовательных и параллельных портах. SCSI-адаптеры знают только об устройствах, подключенных непосредственно к ним. К счастью, за последние несколько лет сложные взаимодействия, необходимые для обеспечения совместной работы этих устройств, были стандартизованы и теперь почти не требуют вмешательства оператора.
В режиме конфигурирования можно выбрать, с какого устройства требуется загружаться. Обычно последовательность загрузки задается в виде правила, например: «сначала — DVD, затем — «флешка» (USB drive), в последнюю очередь — жесткий диск». Распространенным вариантом также считается сетевая загрузка с помощью среды РХЕ.
Когда компьютер определил, с какого устройства следует загружаться, считывается его (устройства) первый блок. Этот сегмент (512 байт) называется главной загрузочной записью (master boot record — MBR). В ней хранится программа, которая сообщает компьютеру о том, в каком разделе диска расположена программа вторичной загрузки (загрузчик операционной системы).
Стандартная программа, находящаяся в главной загрузочной записи, дает компьютеру указание извлечь загрузчик операционной системы из первого раздела диска. В некоторых системах поддерживаются более сложные программы, которые могут работать с несколькими операционными системами и ядрами. Найдя раздел, с которого будет выполняться загрузка системы, программа главной загрузочной записи пытается запустить загрузочную программу, связанную с этим разделом. В случае успеха этой программе передаются полномочия по дальнейшей загрузке ядра.
Программа GRUB (GRand Unified Boot loader), разработанная в рамках проекта GNU, используется как стандартный загрузчик в большинстве UNIX- и Linux-систем, оснащенных процессорами Intel. GRUB поставляется в составе многих дистрибутивов Linux и Solaris (с архитектурой х86) начиная с версии 10. Задача GRUB — выбрать из предварительно подготовленного списка ядро и загрузить его с опциями, заданными администратором.
Существует две ветви развития GRUB: оригинальная, официально именуемая “GRUB Legacy”, и более новая — GRUB 2. Название “GRUB 2” может ввести в заблуждение, поскольку выпуски GRUB 2 в действительности имеют номера версий 1 и 2. Все наши примеры систем в настоящее время используют исходный вариант — GRUB Legacy, и именно эта версия описывается в данной книге. Версия GRUB 2 в концептуальном плане подобна исходной, но отличается синтаксисом файла конфигурации.
По умолчанию GRUB читает параметры загрузки из файла /boot/grub/menu.lst или /boot/grub/grub.conf. Считывание содержимого файла конфигурации происходит в период запуска (что само по себе уже впечатляет), и это позволяет реализовать динамические изменения при каждой загрузке системы. Файлы menu.lst и grub.conf отличаются незначительно, но имеют аналогичный синтаксис. Системы Red Hat используют файл grub.conf, a Solaris, SUSE и Ubuntu — файл menu.lst. Вот образец файла grub.conf:
В этом примере конфигурируется единственная операционная система, которая будет загружена автоматически (default=0), если в течение 10 секунд с клавиатуры не поступят никакие данные (timeout=10). Корневая файловая система для конфигурации “Red Hat Enterprise Linux Server” находится в разделе (hd0,0), что для GRUB означает обращение к первому разделу первого жесткого диска системы (нумерация “первый раздел” и “первый диск” определяется в BIOS).
Программа GRUB загрузит ядро из файла /vmlinuz-2.6.18-92.1.10.е15, а затем выведет начальный образ экрана, хранящийся в файле /boot/grub/splash.xpm.gz. Путь поиска ядра указывается относительно раздела загрузки, который обычно монтируется в каталоге /boot.
Программа GRUB поддерживает мощный интерфейс командной строки и ряд функций, которые позволяют редактировать записи файла конфигурации в ходе загрузки. Для того чтобы перейти в режим командной строки, в окне загрузки GRUB необходимо ввести команду с. Из командной строки можно загружать операционные системы, не отраженные в файле grub.conf, выводить на экран информацию о системе и выполнять простейшую проверку файловой системы. Загрузчик предоставляет также ряд функций, подобных функциям интерпретатора команд, в том числе — функции завершения не полностью введенных команд и перемещения курсора. Любые действия, которые могут быть выполнены с помощью файла grub.conf, могут быть выполнены и посредством командной строки загрузчика GRUB.
Нажатие клавиши <Таb> позволяет вывести на экран краткий список доступных команд. Некоторые из наиболее полезных команд перечислены в таблице ниже.
Для получения подробной информации о загрузчике GRUB и его параметрах командной строки обратитесь к официальному руководству:
Программа загрузчика GRUB позволяет передавать ядру параметры командной строки. Как правило, эти параметры изменяют значения параметров ядра, вынуждают его опросить конкретные устройства, указывают путь поиска демона init или назначают конкретное корневое устройство. Несколько примеров этих параметров приведены в табл. ниже.
Параметры ядра, отредактированные во время загрузки, не сохраняются. Чтобы сохранить изменения на будущие перезагрузки, отредактируйте строку kernel в файле grub.conf или menu.lst.
Ядро Linux постоянно совершенствуется с помощью заплат, повышающих уровень безопасности, исправлений ошибок и новых функций. Но, в отличие от других программных пакетов, старые версии ядра обычно не заменяются новыми. Новые ядра инсталлируются наряду со старыми, чтобы в случае возникновения проблемы вы могли тут же вернуться к старому ядру. Это соглашение помогает администраторам отказаться от модернизации, если заплата ядра разрушает их систему. По прошествии некоторого времени загрузочные меню GRUB заполняются различными версиями ядра. Обычно выбор версии ядра по умолчанию не представляет опасности, но, если окажется, что ваша система не загружается после добавления заплаты, позаботьтесь о возможности выбора другого ядра.
Поскольку на одном персональном компьютере может быть установлено несколько операционных систем, привычной является ситуация, когда компьютер загружается в мультисистемном режиме. Для этого загрузчик должен быть правильно сконфигурирован, чтобы распознать имеющиеся на локальных дисках операционные системы. Далее мы опишем некоторые проблемные блоки мультисистемной загрузки, а затем рассмотрим конкретные примеры конфигурации.
В каждом разделе диска может храниться собственный вторичный загрузчик, однако загрузочный диск должен иметь только одну главную загрузочную запись. Поэтому необходимо решить, какой загрузчик будет “главным”. Как правило, выбор диктуется особенностями имеющихся операционных систем. Для Intel-ориентированных UNIX- и Linux-систем лучше всего в качестве главного загрузчика выбрать GRUB. При двухвариантной загрузке Windows-системы всегда используйте загрузчик GRUB (а не загрузчик Windows).
Конфигурирование загрузчика GRUB для выполнения мультисистемной загрузки во многом аналогично конфигурированию загрузки только одной операционной системы. Прежде чем вносить изменения в файл grub.conf или menu.lst, нужно установить желаемые операционные системы.
Записанные в файле grub.conf параметры конфигурации для загрузки операционной системы Windows отличаются от параметров для загрузки UNIX или Linux.
Параметр chainloader загружает утилиту начальной загрузки из указанного места (в данном случае из сектора 1 первого раздела первого IDE-диска).
Параметр rootnoverify предотвращает попытки загрузчика GRUB выполнить монтирование указанного раздела.
Ниже приведен полный текст файла grub.conf для случая, когда система Windows ХР загружается (по умолчанию) из первого раздела, Red Hat Enterprise Linux — из второго.
Тот факт, что загрузчик GRUB решает многие потенциальные проблемы мультисистемной загрузки, в действительности не смягчает наш врожденный скептицизм в отношении мультисистемных конфигураций.
То, как начинается процесс загрузки, зависит от конкретной системы. Системы с не Intel-процессорами используют специально разработанные программы загрузки, в то время как на персональных компьютерах, в основном, загрузчики стандартизированы (благодаря GRUB).
Для того чтобы выполнить загрузку в однопользовательском режиме при использовании загрузчика GRUB, не нужно применять опции командной строки. Авторы этого загрузчика пришли к выводу, что параметры начальной загрузки должны легко поддаваться изменению и что клавиша <а> — вполне подходящее средство для решения этой задачи. Когда откроется экран начальной загрузки GRUB, выделите нужное ядро и нажмите клавишу <а>, чтобы дополнить опции начальной загрузки. Для того чтобы обеспечить загрузку в однопользовательском режиме, добавьте флаг single (или -s в системе Solaris) в конец существующих опций ядра. Пример типичной конфигурации мог бы выглядеть следующим образом,
grub append> rо root=LABEL=/ rhgb quiet single
Для того чтобы прервать процедуру загрузки и войти в среду OpenBoot PROM на Sun-оборудовании, нажмите одновременно клавиши <L1> и <а>. На современных Sun-клавиатурах клавиша <L1> иногда имеет надпись “STOP”. Для того чтобы выполнить загрузку в однопользовательском режиме из среды OpenBoot PROM, вы можете ввести команду boot -s.
Для загрузки альтернативного ядра под управлением Solaris, как правило, нужно ввести полное Solaris-имя устройства и файла. Имя Solaris-устройства — это длинная странного вида строка символов, которую можно увидеть, введя команду ls -l для файла /dev.
Для того чтобы загрузить ядро, хранимое в виде файла /kernel/backup на том же диске, введите следующую команду в режиме монитора OpenBoot PROM.
boot /devices/sbus@lf,0/SUNW,fas@e,8800000/sd@0,0:a,raw/kernel/backup
Некоторые полезные команды, которые можно ввести из Sun-среды OpenBoot PROM, кратко описаны в таблице ниже.
Процедура загрузки в однопользовательском режиме на рабочих станциях HP-UX зависит от типа машины. Следующий пример взят с рабочей станции HP 9000/735.
Сначала прервите процесс загрузки после соответствующего напоминания. Получив приглашение на ввод команд, введите команду boot pri isl. Эта команда сгенерирует следующее приглашение, которое позволит вам загрузить систему в однопользовательском режиме. Это приглашение должно выглядеть примерно так.
ISL> prompt:
Следующая команда выбирает ядро и загружает систему в однопользовательском режиме.
ISL> prompt: hpux -iS /stand/vmunix
В системах AIX однопользовательский режим называется “профилактическим”. Для его установки, если система еще не загружена, достаточно выбрать соответствующий пункт из меню загрузки. Если система уже загружена, используйте команду telinit S.
После выхода из однопользовательского режима (или — при стандартной загрузке — по завершении работы интерпретатора команд, запущенного с правами суперпользователя) демон init выполняет сценарии запуска системы. Они являются сценариями интерпретатора sh (на самом деле bash), а их местонахождение, содержимое и организация зависят от изготовителя системы.
В большинстве систем используется подход, в котором сценарии нумеруются и выполняются по порядку. Сценарии хранятся в каталоге /etc/init.d, а ссылки на них созданы в каталогах /etc/rc0.d, /etc/rc1.d и т.д. Такая организация совершенно ясна, и поскольку сценарии выполняются по порядку, система может обеспечивать соответствующие зависимости между службами. Эти “пусковые” сценарии как запускают службы, так и останавливают их, поэтому такая архитектура также позволяет надлежащим образом остановить систему.
Ниже приведен перечень задач, которые часто выполняются этими сценариями.
• Задание имени компьютера
• Установка часового пояса
• Проверка дисков с помощью команды fsck
• Монтирование дисков систем
• Удаление старых файлов из каталога /tmp
• Конфигурирование сетевых интерфейсов
• Запуск демонов и сетевых служб
Сценарии запуска обычно довольно многословны и выводят подробную информацию о выполняемых ими задачах. Это может оказать существенную помощь при отладке сценариев или поиске причин зависания системы в процессе загрузки.
Администраторам не следует заниматься модификацией сценариев запуска. Те сценарии, которые принимают данные конфигурации, читают их в форме отдельного файла конфигурации (специфичного для конкретного узла). Вы можете модифицировать вспомогательный сценарий конфигурации и должны быть уверены, что он не будет перезаписан обновлениями.
Сценарии процесса init используются в определенной степени всеми рассмотренными здесь ранее операционными системами. Процесс запуска системы Solaris 10 был полностью переработан. Ubuntu использует “версию” процесса init, известную как Upstart, но мы также её рассмотрим, поскольку она имеет сходство с традиционным процессом init.
Демон init — это первый процесс, который выполняется после завершения загрузки системы, и во многих отношениях он считается самым важным. Его идентификационный номер (PID) всегда равен 1, и сам он является базовым для всех пользовательских и почти для всех системных процессов. Реализации демона init незначительно различаются в разных системах.
Этот демон определяет по меньшей мере семь уровней выполнения, на каждом из которых должен выполняться конкретный набор системных служб. Точное определение каждого уровня в разных системах имеет свои особенности, но следующая информация справедлива для всех систем.
Уровень 0 означает, что система полностью прекратила работу.
Уровень 1 и S означает однопользовательский режим.
Уровни 2—5 предназначены для поддержки работы в сети.
Уровень 6 определяет этап перезагрузки системы.
Уровни 0 и 6 характерны тем, что система не может на них оставаться. Если она на них переходит, то в качестве побочного эффекта происходит завершение работы или перезагрузка. В большинстве случаев система по умолчанию находится на уровне 2 или 3. В Linux уровень 5 используется регистрационными процессами X Windows. Уровень 4 используется редко.
Однопользовательскому режиму традиционно соответствовал уровень 1. На нем запрещены все сетевые сеансы и процессы удаленной регистрации, а в системе выполняется минимальный набор программ. Но поскольку в этом режиме доступ к системе осуществляется с правами суперпользователя, администраторам необходимо, чтобы при загрузке система запрашивала ввод пароля.
Для этой цели был введен уровень S: здесь создается отдельный процесс, отображающий приглашение ввести пароль. В Solaris и AIX уровень S означает, что однопользовательский режим “в действии”, но в Linux уровень S носит переходный характер и завершается сразу после ввода пароля.
Создается впечатление, что уровней выполнения больше, чем нужно. Обычно это объясняется тем, что в телефонном коммутаторе 7 уровней, поэтому считалось, что в UNIX-системе должно быть, как минимум столько же. В действительности в системах Linux и AIX поддерживается до десяти уровней, хотя большинство уровней не определено. В стандартной конфигурации системы AIX значимым является только уровень 2. Уровни 0 и 1 зарезервированы для операционной системы, а уровни 3—9 открыты для использования администраторами.
В файле /etc/inittab содержатся параметры, определяющие, что должен делать демон init на каждом уровне. Формат файла зависит от системы, но основная идея состоит в том, что в нем задаются команды, которые должны быть выполнены (или продолжить выполнение), когда система переходит на конкретный уровень.
В процессе загрузки демон init последовательно продвигается от уровня 0 к уровню по умолчанию, заданному в файле /etc/inittab. Чтобы осуществить переход между соседними уровнями, демон выполняет команды из этого файла. Аналогичные действия, только в обратном порядке, происходят при останове системы.
Команда telinit позволяет изменить уровень выполнения демона init, когда система полностью функциональна. Например, команда telinit 3 переводит демон init на уровень 3. Самым полезным аргументом команды telinit является -q, который предписывает init перечитать файл /etc/inittab.
К сожалению, структура файла inittab несколько недоработана и недостаточно хорошо согласуется с реальным механизмом запуска и остановки служб в системах UNIX. Для того чтобы сделать этот файл более эффективным, в демоне init реализован дополнительный, абстрактный, уровень. Он представлен в виде команды, которая исходит из файла inittab и осуществляет смену уровней. Эта команда, в свою очередь, запускает сценарии из каталога, зависящего от целевого уровня. Они-то и переводят систему в новое состояние.
Этот дополнительный уровень не до конца разработан в системах AIX. Поэтому управление службами в системах AIX определяется только содержимым файла inittab. Кроме того, AIX-сценарии запуска немного отличаются от соответствующих сценариев в других системах.
Большинство современных дистрибутивов Linux по умолчанию выполняет загрузку на уровень 5, что может быть не подходящим для систем, которым не требуется запускать дисплейный сервер (в среде X Window System). Изменение используемого по умолчанию уровня выполнения не представляет сложности. Следующая строка из файла inittab компьютера, работающего под управлением системы SUSE, определяет уровень 5 выполнения в качестве используемого по умолчанию.
id:5:initdefault:
Системным администраторам обычно не приходится работать непосредственно с файлом /etc/inittab, так как существующие сценарии подходят для большинства случаев. Далее мы практически не будем упоминать об этом файле и взаимодействии демона init со сценариями запуска системы. Просто, когда мы говорим о том, что демон init выполняет такой-то сценарий, нужно понимать следующее: связь со сценарием может быть косвенной.
Основные копии сценариев запуска хранятся в каталоге /etc/init.d. Каждый сценарий отвечает за запуск одного демона или определенной подсистемы. Сценариям можно передавать аргументы start и stop, которые означают, что соответствующая служба должна быть запущена либо остановлена. Большинство сценариев понимает также аргумент restart, который эквивалентен связке stop+start. Обладая правами системного администратора, можно вручную запускать или останавливать нужные службы, вызывая соответствующий сценарий из каталога init.d и передавая ему требуемый аргумент.
Ниже показан несложный сценарий, позволяющий запускать, останавливать и перезапускать демон sshd.
Сценарии каталога /etc/init.d способны запускать и останавливать отдельные службы, но, чтобы перейти на требуемый уровень, главный управляющий сценарий, выполняемый демоном init, должен получить дополнительную информацию о том, какие сценарии и с какими аргументами нужно запустить. Управляющий сценарий не просматривает непосредственно каталог init.d, а обращается к каталогу rcуровень.d, где уровень — это номер требуемого уровня выполнения, на который осуществляется переход (rc0.d, rc1.d и т.д.).
В каталогах rcуровень.d обычно содержатся символические ссылки на сценарии каталога init.d. Имена ссылок начинаются с префикса S или к, за которым следует номер и имя службы, управляемой сценарием (например, S34named).
Если демон init переходит на более высокий уровень, он выполняет все сценарии с префиксом S (“start” — запуск) в порядке возрастания номеров, причем каждому сценарию передается аргумент start. Когда осуществляется переход на более низкий уровень, запускаются сценарии с префиксом К (“kill” — уничтожить) в порядке убывания номеров, и всем им передается аргумент stop.
Эта схема позволяет администраторам очень точно управлять порядком запуска служб. Например, запуск сценария sshd до запуска сетевых интерфейсов лишен смысла. Хотя в системе Red Hat и сеть, и сценарий sshd выполняются на уровне 3, сценарию network присваивается порядковый номер 10, а сценарию sshd — 55. Поэтому можно не сомневаться, что сценарий network будет запущен раньше. При добавлении новых служб необходимо учитывать подобные взаимосвязи.
Чтобы сообщить системе, когда следует запускать тот или иной демон, нужно создать символическую ссылку в соответствующем каталоге. Например, следующие команды информируют систему о том, что демон печати cupsd должен быть запущен на уровне 2 и остановлен при завершении работы системы.
# ln -s /etc/init.d/cups /etc/rc2.d/S80cups
# ln -s /etc/init.d/cups /etc/rc0.d/K80cups
Первая ссылка свидетельствует о том, что сценарий запуска /etc/init.d/cups должен быть выполнен одним из последних при переходе на уровень 2 и ему должен быть передан аргумент start. Вторая ссылка сообщает, что в процессе завершения работы системы сценарий /etc/init.d/cups должен быть запущен относительно рано, причем с аргументом stop. В некоторых системах процессы останова и перезагрузки трактуются по-разному, поэтому необходимо также создать символическую ссылку в каталоге /etc/rc6.d, чтобы обеспечить корректный останов демона при перезагрузке системы.
Сценарии запуска в дистрибутивах Linux сильно отличаются друг от друга. В основу сценариев Red Hat положен подход, реализованный в демоне init, причем в некоторых строках разобраться довольно трудно.
На каждом уровне выполнения демон init вызывает сценарий /etc/rc.d/rc, передавая ему номер уровня в качестве аргумента. Этот сценарий может выполняться как в обычном режиме, так и в режиме подтверждения, когда перед выполнением каждого сценария выдается запрос.
Сценарии запуска хранят файлы блокировок в каталоге /var/lock/subsys. Наличие файла блокировок (с таким же именем, как у сценария запуска) служит признаком того, что данная служба уже “занята”. Сценарии запуска создают файлы блокировок при выдаче команды start и удаляют их при выполнении команды stop.
В системах Red Hat управлять службами можно с помощью команды chkconfig. Эта команда добавляет или удаляет сценарии запуска из системы, управляет уровнями выполнения, на которых они работают, и выводит уровни, для которых сконфигурирован сценарий. Для получения информации о применении этого простого и удобного средства можно использовать команду man chkconfig.
В Red Hat также предусмотрен сценарий /etc/rc.d/rc.local (не каталог), который запускается во время загрузки. Этот последний сценарий, выполняемый как часть процесса загрузки, позволяет добавлять нюансы, характерные для конкретного узла или для выполнения задач после загрузки.
Когда появится сообщение “Welcome to Red Hat Enterprise Linux”, можно нажать клавишу <i>, чтобы продолжить загрузку в режиме подтверждения. Однако подтверждение о нажатии клавиши не отображается. Система продолжит монтировать локальные файловые системы, активизировать разделы подкачки, загружать таблицы клавиш и вести поиск модулей ядра. Только после перехода на уровень 3 система начнет выдавать запросы на подтверждение.
Режимы интерактивной и однопользовательской загрузки начинаются в одной и той же точке. Если в процессе загрузки возникли серьезные проблемы и этой точки достичь невозможно, воспользуйтесь для загрузки DVD-диском или USB флешкой.
Можно передать ядру параметр init=/bin/sh, чтобы заставить его вызвать интерпретатор команд однопользовательского режима еще до того, как будет запущен демон init*. В этом случае все действия по запуску системы придется осуществлять вручную, включая выполнение команды fsck и монтирование локальных файловых систем.
*В случае, если в вашей системе был поврежден файл, содержащий таблицу клавиш, поскольку система Red Hat загружает этот файл даже в однопользовательском режиме, переход в этот режим не всегда позволяет решить проблему. Передача параметра init=/bin/sh может оказаться единственным безопасным способом загрузить систему и исправить ошибку. Этот прием эффективен и в других случаях.
Повлиять на процесс начальной загрузки в Red Hat можно путем модификации конфигурационных файлов, находящихся в каталоге /etc/sysconfig. Назначение элементов этого каталога описано в таблице ниже.
Для некоторых элементов списка необходимы дополнительные пояснения.
Файл network содержит адрес шлюза, имя хоста и другие важные установки, которые действуют по умолчанию и применяются ко всем сетевым интерфейсам.
Каталог network-scripts содержит вспомогательные файлы, связанные с конфигурацией сети. Единственное, что может потребоваться в нем изменить, — это файлы с именами ifcfg-интерфейс. Например, файл network-scripts/ifcfg-eth0 хранит параметры конфигурации интерфейса eth0, в частности его IP-адрес и сетевые опции.
Подробнее конфигурирование сетевых интерфейсов будет рассмотрено в следующих темах.
Файл sendmail содержит две переменные: DAEMON и QUEUE. Если переменная DAEMON равна значению yes, система запустит программу sendmail в режиме демона (-bd) в процессе начальной загрузки. Переменная QUEUE информирует программу sendmail о том, каков интервал обработки очереди почтовых сообщений (-q). Стандартная установка — 1 час.
Сценарии запуска систем SUSE подобны сценариям Red Hat, по крайней мере, по части общей организации. Эти сценарии не только четко организованы, но надежны и хорошо документированы. Стоит сказать спасибо разработчикам, которые отвечают за эту часть операционной системы.
Как и в системе Red Hat, на каждом уровне выполнения демон init вызывает сценарий /etc/rc.d/rc, передавая ему номер уровня в качестве аргумента. Сценарии данного пакета хранятся в каталоге /etc/init.d, а их файлы конфигурации — в каталоге /etc/sysconfig. Прекрасное краткое описание процесса запуска системы SUSE можно найти в файле /etc/init.d/README.
Хотя файлы конфигурации запуска как системы SUSE, так и Red Hat собраны в каталоге /etc/sysconfig, конкретные файлы внутри этого каталога в значительной мере различны. (В частности, в целом файлы SUSE сопровождаются достаточно подробными комментариями.) Необходимые параметры вызываются посредством установки переменных среды интерпретатора, к которым затем обращаются сценарии, хранящиеся в каталоге /etc/init.d. Некоторые подсистемы требуют более подробного конфигурирования. Такие системы, нуждающиеся в нескольких файлах конфигурации, имеют приватные подкаталоги вроде sysconfig/network.
Файл windowmanager — типичный пример файла, хранящегося в каталоге sysconfig.
Каждой переменной предшествует информация о конфигурации, считываемая утилитой YaST, и подробное описание назначения переменной. Например, в файле windowmanager переменная DEFAULT_WM определяет диспетчер окна рабочего стола, используемый системой X.
Пакет SUSE содержит также команду chkconfig, которая позволяет управлять сценариями запуска системы. Она коренным образом отличается от версии, предоставляемой системой Red Hat, но также является эффективным средством управления сценариями.
YaST — специализированная утилита графической конфигурации SUSE, которая управляет многими аспектами этой системы.
Начиная с выпуска “Feisty Fawn” в начале 2007 года, в системах Ubuntu традиционный демон init был заменен службой начальной загрузки на основе событий Upstart, которая используется и некоторыми другими дистрибутивами Linux. Служба Upstart обрабатывает переходы из одного состояния системы в другое (например, при изменении состава оборудования) более элегантно, чем это делает демон init. Кроме того, Upstart значительно сокращает время загрузки.
Служба Upstart организует запуск и останов других служб и задач в ответ на такие события системы, как добавление устройства или отключение сетевого диска. Из соображений совместимости служба Upstart также эмулирует традиционные уровни выполнения демона init. Но сценарии запуска и останова обрабатываются несколько не так, как при использовании демона init.
Демон Upstart использует файлы определения заданий из каталога /etc/event.d (а не файл inittab). Задание в концептуальном плане подобно сценарию загрузки, т.е. оно выполняет некоторую последовательность команд, а затем возвращает управление демону Upstart. Коллекция заданий в системе Ubuntu следующим образом.
Со временем все больше сценариев загрузки будут преобразованы в Upstart-задания, а пока для загрузки системы демон Upstart использует сценарии эмуляции уровней выполнения. Например, сценарий rс2 (в виде файла /etc/rc2.d/rc) выполняет все сценарии запуска для уровня 2.
Из-за необходимости поддержки этой совместимости Ubuntu-администраторы должны использовать Ubuntu-команду update-rc.d для обслуживания ссылок на сценарии запуска в рамках rc-каталогов. Вот как выглядит синтаксис этой команды.
update-rc.d служба { start | stop } последовательность уровней.
Команда update-rc.d принимает в качестве аргументов порядковый номер (имеется в виду порядок выполнения сценариев загрузки) и нужные уровни выполнения. Для обозначения конца списка уровней используется символ точки.
Службы, которые при смене уровня стартуют позже, должны останавливаться раньше при выходе системы с данного уровня. Например, если сервер печати CUPS во время загрузки запускается с порядковым значением 80, он должен остановиться приблизительно с номером 20, т.е. поближе к началу процесса останова. Команда update-rc.d, добавляющая соответствующие ссылки, должна иметь такой вид.
Эта команда добавляет “стартовые” экземпляры сценариев с порядковым номером 80 на уровнях выполнения 2-5, а также — “финишные” экземпляры с порядковым номером 20 на уровнях S, 1 и 6.
Устанавливаемый по умолчанию уровень управляется двумя telinit-строками в файле /etc/event.d/rc-default. Изменить уровень выполнения можно, отредактиров файл rc-default в любом текстовом редакторе.
Демон Upstart также управляет логинами на терминалах, используя задания с tty*-именами.
Традиционные UNIX- и Linux-системы были очень требовательны в отношении процедуры выключения. Современные системы более терпимы (особенно если речь идет о высоконадежной файловой системе), но все же лучше корректно завершать работу, если это возможно. Неправильное выключение компьютера может привести к появлению трудно обнаруживаемых, неочевидных ошибок, а иногда и к полному краху системы. Базы данных (которые не прекращают свою работу корректно) “славятся” проблемами разрушения данных и их целостности.
Теоретически базы данных должны быть особенно устойчивыми к такой форме разрушения, но обычно всё свидетельствует об обратном.
Перезагрузка системы на персональном компьютере — средство решения почти всех проблем. Проблемы, возникающие в Linux, как правило, скрытые и сложные, поэтому перезагрузка дает ожидаемый результат гораздо реже, чем в других системах.
Если вы модифицируете один из сценариев запуска системы или вносите в систему существенные изменения, то нужно перезагрузиться хотя бы для того, чтобы проверить, успешно ли функционирует система после вашего вмешательства. Если какая-либо проблема не проявится в течение нескольких ближайших недель, впоследствии вы вряд ли вспомните подробности последних изменений.
Команда shutdown — самый безопасный и корректный способ остановить или перезагрузить систему либо вернуться в однопользовательский режим. Она переносит нас во времена использования систем, работающих в режиме разделения времени, поэтому такой подход порой кажется анахроничным на настольных компьютерах.
К сожалению, почти все изготовители систем решили приложить “свою руку” к аргументам команды shutdown. Мы рассмотрим эту команду в общих чертах, а затем обсудим ее синтаксис и аргументы, используемые на каждой платформе.
Можно дать команде shutdown указание делать паузу перед остановом системы. Во время ожидания команда посылает зарегистрированным пользователям через постепенно укорачивающиеся промежутки времени сообщения, предупреждая о приближающемся событии. По умолчанию в сообщениях говорится о том, что система заканчивает работу, и указывается время до момента останова. При желании администратор может добавить собственное короткое сообщение, в котором поясняется, почему система останавливается и сколько примерно времени придется подождать, прежде чем снова можно будет войти в систему. После выполнения команды shutdown пользователи будут лишены возможности входа в систему, но они будут видеть сообщение, предусмотренное администратором.
С помощью команды shutdown (в большинстве ее версий) можно указать, что должна сделать система после выполнения команды: остановиться, перейти в однопользовательский режим или перезагрузиться. Можно также задать, должна ли после перезагрузки выполняться принудительная проверка дисков с помощью команды fsck. В современных системах с объемными дисками полное выполнение команды fsck может занять много времени; и эту проверку можно пропустить. (Большинство систем автоматически пропускает эту проверку, если файловые системы были корректно демонтированы.)
В таблице ниже приведены аргументы команды shutdown для различных систем.
Например, следующая Linux-команда напоминает пользователям о запланированной процедуре сервисного обслуживания и отключает систему в 9:30 утра.
$ sudo shutdown -h 09:30 "Going down for scheduled maintenance. Expected downtime is 1 hour."
Можно также задать относительное время отключения. Например, приведенная ниже команда запустит процесс выключения через 15 минут:
$ sudo shutdown -h +15 "Going down for emergency disk repair."
Команда halt выполняет все основные операции, необходимые для останова системы. Обычно она вызывается командой shutdown -h, но может применяться, и сама по себе. Команда регистрирует в журнальном файле факт останова, уничтожает несущественные процессы, выполняет системный вызов sync, дожидается завершения операций записи на диск, а затем прекращает работу ядра.
При наличии опции -n системный вызов sync подавляется. Команда halt -n используется после восстановления корневого раздела командой fsck, чтобы ядро не могло затереть исправления старыми версиями раздела, хранящимися в кеше.
Команда reboot почти идентична команде halt. Разница лишь в том, что система перезагружается, а не останавливается. Режим перезагрузки вызывается также командой shutdown -r.
Дополнительную информацию по запуску и останову систем на базе UNIX/Linux вы можете получить на след. ресурсах:
UNIX AND LINUX SYSTEM ADMINISTRATION HANDBOOK. Глава 3. Запуск и останов системы
