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

Гнездо USG

Уровни выполнения

В системах из гнезда USG (к которым по общим признакам относится и Linux, хотя формально Linux не наследует System V) вводится понятие уровня выполнения (run level). Уровень выполнения системы - это некоторый обобщенный профиль ее работы: из всех возможных системных служб на каждом уровне выполнения некоторые должны быть запущены, а некоторые - обязательно остановлены. Уровни выполнения нумеруются, и чем больше номер, тем больше услуг предоставляет система. Некоторые уровни выполнения стандартизованы, в отношении других есть только договоренность.

Уровень 0 соответствует останов системы (такому профилю, в котором все системные службы должны быть остановлены). Уровень 6 соответствует перезагрузке системы: останову с последующим запуском. Перезагрузка может понадобиться, если администратор или иные стихии привели систему в неработоспособное состояние, но чаще - при замене ядра и других подобных операциях.

Уровень 1 - специальный, он называется однопользовательским. Данный уровень предоставляет единственному пользователю - root - единственный канал управления системой (как правило, с системной консоли), при этом другие терминальные линии не обслуживаются и никаких других пользователей в системе зарегистрировать нельзя. Обычно никакие файловые системы, кроме корневой, при этом не смонтированы (что позволяет делать с остальными файловыми системами существенно большее, чем когда смонтированы и они). Иногда в однопользовательском режиме система вообще не спрашивает пароля пользователя root, а сразу запускает на консоли shell с нулевым UID. Это, конечно, стоит допускать только в случае защищенной консоли (secure console), когда к физическому устройству-консоли имеет доступ только тот, кто и так знает пароль root. Например, терминал - консоль сервера, запертого в серверной комнате на ключ, который есть только у системного администратора, можно (но не обязательно!) считать защищенным, а клавиатуру+монитор персональной Linux-станции в офисе - нельзя.

Уровень 2, по договоренности, соответствует многопользовательскому режиму работы, при котором активизируются все терминальные линии со стандартной процедурой аутентификации пользователя (см. лекцию 10) и запускаются кое-какие системные службы.

Уровень 3 принято задействовать для многопользовательского сетевого режима работы: именно при входе на этот уровень выполнения запускаются всевозможные сетевые службы, превращая систему в сетевой сервер (если это нужно). Строгой договоренности, когда именно настраивать сеть (давать возможность работать с ней клиентским программам) нет: иногда это делается на уровне 2, а иногда - на уровне 3.

В Linux часто используется и уровень 5, на котором дополнительно запускаются графические сервисы (обычно графический сервер X11 Window System и служба аутентификации). Можно использовать и другие уровни (4 и 7-9), но для чего они - в точности не определено. В некоторых системах гнезда USG (в частности, в Solaris) для того, чтобы добраться до более высокого уровня выполнения, необходимо последовательно пройти все более низкие, начиная с первого. При этом для перехода с уровня на уровень достаточно только внести изменения в состоянии системы - например, запустить сетевые службы при переходе со второго уровня на третий. С другой стороны, такая схема требует строго вложенных функциональностей, а если более высокий уровень не целиком повторяет возможности более низкого - начинаются неувязки.

Inittab

Стартовав, init читает файл /etc/inittab. В этом файле, довольно замысловатом по структуре, он находит много информации. Там написано, на какой уровень выполнения следует переходить при старте системы (обычно 3 или 5), какие действия выполнять сразу после запуска и при входе на каждый уровень, что делать при выключении или нестабильности питания; возможно, что-то еще. Сами действия могут быть с точки зрения init однократными или повторяемыми (когда соответствующий процесс завершается, init повторно запускает его). Кроме того, init может ждать завершения процесса или запускать его в фоне, умеет запускать определенные процессы в специфических состояниях системы (можно, например, научить его распознавать любимое Ctrl+Alt+Del и переходить на уровень 6 после нажатия этих клавиш).

Особенности поведения init и структура файла inittab описаны в соответствующих руководствах, нам важно только вот что: описанный ниже механизм перехода системы с одного уровня выполнения на другой, хоть и соответствует давней договоренности, но задается отчасти структурой самого inittab, отчасти вызываемым из него универсальным стартовым сценарием. Оба файла - текстовые и по крайней мере один из них - inittab - предназначен для редактирования (системным администратором, конечно). Так что названия самих сценариев могут быть слегка различными в разных системах, и ничего не стоит изменить логику начальной загрузки до неузнаваемости, вот только надо ли?

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

Современные внешние устройства умеют сообщать достаточно данных для автоматического их распознавания (некоторое уникальное для однотипных устройств имя и настройки, выданные им шиной. В Linux такая утилита для шины PCI называется lspci, а в FreeBSD - scanpci ), однако полностью переложить на систему подбор модулей нельзя. Для этого все изготовители аппаратуры должны давать привязку устройств к драйверам всех операционных систем (или даже изготовлять новые драйверы), что невозможно. По-хорошему, каждое внешнее устройство должно полностью соответствовать какому-нибудь опубликованному стандарту: тогда было бы достаточно одного драйвера, а какой-нибудь ярлычок стандарта определял бы уникальное имя устройства. Это совершенно нереально, потому что множество изготовителей аппаратуры (особенно самой дешевой и самой дорогой) зарабатывают именно тем, что скрывают архитектуру продаваемого устройства, дабы не пострадать от конкурентов.

Схема ".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...

Гнездо BSD

"Линейный" стартовый сценарий

Рассмотрим теперь, как ведет себя init в системах семейства BSD. В этих системах нет понятия уровня выполнения, поэтому в целом init работает очень просто: сначала выполняет стартовый сценарий /etc/rc, после чего разбирает файл /etc/ttys, в котором сказано, на каких терминальных линиях какие обработчики должны быть запущены (в основном это getty, а сам файл, как видно, выполняет одну из ролей inittab ). Когда процесс из ttys завершается, init запускает его повторно. Кстати сказать, если вы изменили /etc/ttys (или /etc/inittab ) и хотите, чтобы init прочитал заново настройки, ему, как и большинству демонов UNIX, можно послать сигнал HUP (Hang UP): kill -HUP 1 (конечно, это может сделать только тот, кто имеет право изменять inittab - суперпользователь).

Несмотря на то что в BSD нет понятия уровня выполнения, понятие однопользовательского режима там есть. Соответствующий параметр передается ядру, а оно передает аналогичный параметр init. В BSD init, запущенный в однопользовательском режиме, не выполняет /etc/rc и не разбирает строки /etc/ttys, не относящиеся к системной консоли. Вместо этого init непосредственно запускает /bin/sh на консоли, если она защищенная, или вдобавок предварительно спрашивает пароль суперпользователя, если она незащищенная. После того как shell завершается, init переходит в многопользовательский режим и работает так, как описано в этой лекции.

Видимо, когда-то давно ." /etc/rc.conf (см. лекцию 11) (в некоторых системах - /etc/rc.config ) - настройки.

Однако через некоторое время выяснилось, что и rc.config не слишком хорош, потому что перечисленные в нем, иногда безо всякого порядка, все системные настройки (числом более трех сотен) - прямое нарушение У. Порядок строк вида переменная=значение в этом файле сам по себе неважен, да еще средство автоматической настройки в FreeBSD, /stand/sysinstall, дописывает все сделанные с его помощью изменения в конец rc.config. Затем в каталоге /etc появился подкаталог /etc/defaults, в котором хранится в неизменном виде хорошо откомментированный rc.conf и некоторые другие настройки системы. В rc.conf из /etc записываются теперь только различия желаемой конфигурации системы и /etc/defaults/rc.conf, а их, как правило, раз в десять меньше. Итак, всякий сценарий, желающий использовать настройки системы, выполняет сначала команду . /etc/defaults/rc.conf, а затем . /etc/rc.conf.

С вынесением настроек в отдельный файл появилась возможность разбить /etc/rc на несколько сценариев, отвечающих за различные стадии загрузки и различные подсистемы. Некоторые подсистемы при разных вариантах настройки могут быть незадействованы, а значит, их сценарии запускать незачем. Так появились /etc/rc.network (настройка сети и сетевых служб), /etc/rc.firewall (настройки межсетевого экрана), /etc/rc.i386 (настройка параметров, специфичных для i386), /etc/rc.syscons (настройка виртуальных консолей), /etc/rc.diskless (для бездисковых систем) и некоторые другие (в FreeBSD4 - порядка 20 штук). В этих сценариях тоже включаются оба файла rc.conf, так что, если это имеет смысл, их можно запускать отдельно, не из /etc/rc. Например, для перезапуска firewall с консоли можно использовать команду sh /etc/rc.firewall тип.

Эти сценарии вызываются (или не вызываются) из /etc/rc в том порядке, в котором они там встречаются. Предполагается, что все упомянутые в них службы уже установлены в системе, а если они не установлены, то и в rc.conf не включены.

Использовать стартовые сценарии BSD для останова служб не представляется возможным. Вручную службы можно останавливать и перезапускать сигналами (TERM и HUP) - если, конечно, демоны написаны в соответствии с договоренностями - или специальными утилитами вроде lpc, управляющей подсистемой печати. Операции, необходимые для останова всей системы (размонтировать сетевые диски, сохранить динамические настройки некоторых служб, остановить штатным способом службы, которые нельзя завершить сигналом и дождаться их полного останова и т. п.), выполняет сценарий /etc/rc.shutdown.

Недостатки линейной схемы загрузки

Линейная схема неплохо работает только в случае так называемой базовой системы (core system) - системы, все программные продукты которой известны, оттестированы на совместимость друг с другом и отражены в совместных стартовых сценариях вроде ."): синтаксическая ошибка в любом из них приведет к сбою самого rc, и процедура начальной загрузки аварийно остановится. Значит, для интерпретации каждого управляющего сценария нужно запустить собственную копию shell - 30 лет назад эта операция требовала очень много системного времени: новый процесс, дополнительная оперативная память, открытие нового файла...

Сейчас эти различия уже неактуальны: размер однотипных программ растет ), так что сами стартовые сценарии и упомянутые системные вызовы работают уже слишком быстро по сравнению с обработкой пользовательских данных. Дело в том, что объем хранилищ данных растет вместе с быстродействием компьютера: наибольший размер хранилища данных зависит от того, как долго пользователь согласен ждать окончания операции выборки. Поэтому, например, скорость работы команды fsck, проверяющей цельность файловой системы, почти не увеличилась.

Если речь идет о необязательных компонентах - таких как WWW-сервер или какой-нибудь экзотический telserver (talk via telnet), которые тем не менее должны запускаться при старте системы и останавливаться при останове, ничего лучше .d-схемы все равно нет. Поэтому в FreeBSD4 есть и каталог rc.d, только лежит он, согласно правилам FreeBSD, не в /etc, а в /usr/local/etc. Этот каталог - аналог init.d из USG, с той лишь разницей, что USG -система самостоятельно запускает только ссылки на содержимое init.d из каталогов уровней, а BSD-система запускает их непосредственно из rc.d, все с параметром start при старте системы и с параметром stop при останове.

Требования BSD к управляющему сценарию такие: он должен быть исполняемым (иметь x-бит), обрабатывать ключи start и stop, и его имя должно заканчиваться на .sh. Последнее требование позволяет при установке необязательного сервиса класть в /usr/local/etc/rc.d управляющий сценарий с именем, скажем, myservise.sh.sample, который не будет запускаться, пока системный администратор не посмотрит внутрь него и не переименует в myservise.sh. Очередность выполнения сценариев из rc.d при старте FreeBSD4 - лексикографическая, при останове - обратная лексикографическая, поэтому надо быть внимательным при запуске зависящих друг от друга подсистем.

Схема ".d"

Несмотря на очевидные недостатки "линейной" схемы стартовых сценариев в стиле BSD4.4 по сравнению с .d-схемой, в FreeBSD и некоторых других системах не решались на нее переходить. Главная трудность заключалась в выборе того самого двузначного числа, которое в .d-схеме задает порядок выполнения сценариев. Включение очередного сценария в rc.d требует некоторого размышления, каким именно по порядку он должен идти. В случае необязательных служб этот порядок почти неважен, так как они мало зависят друг от друга. Но если этот сценарий запускает часть самой системы, нарушение порядка может привести ее в нерабочее состояние. В конце концов разработчики NetBSD решили вообще отказаться от ручного, заранее заданного определения очередности выполнения сценариев - и от числа в имени сценария тоже.

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

Схема NetBSD оказалась удачной и в новой ветке FreeBSD - FreeBSD5 - ее скопировали. Количество "линейных" сценариев резко сократилось (из них некоторые остались по соображениям совместимости; скорее всего, их в последующих версиях FreeBSD5 ликвидируют). Появился каталог /etc/rc.d, в котором и лежат управляющие сценарии (числом более сотни) и некоторая политика оформления их заголовков. Подробнее обо всем этом расскажет руководство по rc и rcorder.