Системная начальная загрузка

Схема ".d"

Выполнив rc.sysinit, init выбирает из inittab уровень, на который система должна перейти по умолчанию. В Linux этим занимается командный сценарий /etc/rc.d/rc, которому в качестве параметра командной строки передается номер уровня. Именно запуск rc с параметром и записан в inittab для каждого уровня выполнения, с указанием init дождаться, пока сценарий завершит работу. Переход на уровень - это выполнение соответствующего уровню набора управляющих (или старт-стопных) сценариев, который выбирается и выполняется из-под rc.

Каждый такой сценарий должен распознавать как минимум два параметра командной строки - start и stop. Запущенный с ключом start, сценарий запускает соответствующую службу (например, подсистему печати или WWW-сервер), а запуск с ключом stop эту службу останавливает. При установке некоторой службы в систему ее управляющий сценарий помещается в каталог /etc/init.d. Суффиксом .d обычно отмечается каталог (directory) однотипных файлов, каждый из которых используется какой-нибудь определенной программой. (Очень часто в более ранних версиях UNIX вместо .d -каталога использовался один файл, и при добавлении или удалении программного продукта приходилось этот файл автоматически преобразовывать; если к нему уже успевал приложить руку системный администратор, об автоматизме можно было говорить лишь гипотетически). Каталог /etc/init.d в ALT Linux - символьная ссылка на /etc/rc.d/init.d, а в некоторых версиях Linux /etc/init.d не было вовсе, что слегка нарушало единообразие. Иногда от управляющего сценария требуется еще обрабатывать ключи status, диагностику состояния службы, и restart, перезапуск службы (это не всегда просто stop+start ). Перечисленные параметры не играют роли при переходе с одного уровня выполнения на другой, зато их удобно использовать, управляя системой вручную.

В /etc (для Linux - в том же /etc/rc.d ) есть каталоги вида /etc/rc номер_уровня.d, в которых помещены специальным образом поименованные символьные ссылки на управляющие сценарии. Если при входе на уровень некоторая служба должна быть остановлена, в соответствующий каталог помещается ссылка на ее управляющий сценарий, имя которой начинается на букву K (от KILL ). Если служба должна быть запущена, ссылка на ее управляющий сценарий должна начинаться на S (от Start ). Сначала rc выполнит по очереди (в лексикографическом порядке) все начинающиеся на K сценарии из этого каталога, передавая каждому параметр stop. В некоторых системах стоп-сценарий вызывается, только если его служба действительно была запущена; в этом случае значимо сообщение об ошибке: например, служба успела остановиться сама собой, что нехорошо. Потом - упорядоченно и по очереди - выполняются с параметром start все начинающиеся на S сценарии.

В некоторых системах строгих требований, кроме определенной первой буквы, к именам в /etc/rc?.d/ не предъявляется, но считается хорошим тоном второй и третий символы имени сценария делать двузначным числом, а уж потом добавлять имя сервиса. Тогда, во-первых, строго определится очередность выполнения управляющих сценариев, потому что сценарий с меньшим номером выполнится безусловно раньше, а во-вторых, даже при совпадении этих чисел, конфликта имен не будет, потому что разные службы называются по-разному. В тех системах, где флаг запуска и останова службы зависит от имени стартового или остановочного сценария (ALT Linux хранит эти флаги в /var/lock/subsys/ ), такое именование ссылок на управляющие сценарии обязательно.

Например, в ALT Linux при входе на уровень 2 (многопользовательский без сети) требуется прекратить использовать сетевые файловые системы ( netfs ) и запустить системную службу выполнения действий по расписанию (crond). На уровне 3 (многопользовательском сетевом) обе службы должны быть запущены, а на уровне 0 ( останов системы ) - остановлены. Для этого в каталогах /etc/rc.d/rc0.d, /etc/rc.d/rc2.d и /etc/rc.d/rc3.d помещено по две ссылки на управляющие сценарии. (К нашей теме это не относится, но о том, что такое ls -og и egrep, можно почитать в руководствах, а о *grep - еще и в лекции 14; к теме относится, что приведенные ссылки указывают не в /etc/init.d, а в /etc/rc.d/init.d, как это сложилось в Linux):

linux$ /bin/ls -og /etc/rc.d/rc[023].d | egrep ^/|"
crond|netfs"
/etc/rc.d/rc0.d:
lrwxrwxrwx  1   15 Oct 31 16:41 K60crond -> ../init.d/crond
lrwxrwxrwx  1   15 Oct 31 16:41 K75netfs -> ../init.d/netfs
/etc/rc.d/rc2.d:
lrwxrwxrwx  1   15 Oct 31 16:41 K75netfs -> ../init.d/netfs
lrwxrwxrwx  1   15 Oct 31 16:41 S40crond -> ../init.d/crond
/etc/rc.d/rc3.d:
lrwxrwxrwx  1   15 Oct 31 16:41 S25netfs -> ../init.d/netfs
lrwxrwxrwx  1   15 Oct 31 16:41 S40crond -> ../init.d/crond

Обратите внимание, что останов служб происходит обычно не в том же порядке, что запуск; логичнее всего предположить, что порядок будет обратным, раз уж сумма чисел при K и S у одинаковых сценариев равна 100, однако бывают ситуации, когда порядок останова следует выстраивать специально.

Если понятие уровней выполнения представляется чем-то слегка надуманным, то описанная .d-схема хранения и запуска сценариев выглядит весьма удобной. У нее есть, по крайней мере, три достоинства.

Первое - соответствие У, поскольку в каждом сценарии сосредоточено все, относящееся только к конкретной службе. Второе - соответствие З, поскольку общие для всех сценариев части, вроде оформления вывода, журнализации запуска и останова и т. п., обычно уже включены в /etc/rc.d/rc или хранятся во включаемом сценарии (в Linux - /etc/rc.d/init.d/functions ), так что на долю разработчика сценария остается только логика запуска, а пользователю-администратору для запуска или останова службы достаточно просто запустить сценарий. Третье - независимость служб на уровне размещения в файловой системе: поводом для включения некоторой службы в работу будет появившийся в /etc/init.d файл. Указание запускать или не запускать сервис на том или ином уровне тоже сведено до одной операции - заведения соответствующей ссылки в соответствующем каталоге /etc/rc?.d.

Дождавшись выполнения rc, init переходит к другим записям в inittab, относящимся к текущему уровню выполнения. Обычно там остаются только перезапускаемые (respawn) действия: процессы, которые init запускает в фоне, а когда какой-нибудь из них завершается, запускает вновь. Так, например, устроен запуск getty на обслуживаемых терминальных линиях: как известно из главы 8, getty определяет активность на терминальной линии и запускает login ; login проверяет входное имя и пароль пользователя и запускает shell, а shell завершается при выходе пользователя из системы. Тогда init замечает, что процесс с указанным PID умер, и перезапускает getty. В качестве параметра getty в inittab вписано имя терминала и его тип.

Системная начальная загрузка считается законченной, когда все перезапускаемые процессы из initab запущены и init ничего не остается, как следить за ними. В это время пользователи уже радостно вводят пароль программе login...