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

Гнездо 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 был единственным стартовым сценарием, в котором сначала определялись в виде переменных shell разнообразные настройки системы, а потом, в зависимости от их значения, производились необходимые для начала работы действия, вроде проверки и монтирования дисков, настройки сети, запуска основных системных демонов и т. п. Очень скоро стало понятно, что кусок с настройками системы системный администратор редактирует довольно часто, а кусок со сценарием - почти никогда. Тогда этот файл был поделен на две части: сам /etc/rc - сценарий и включаемые в него командой " ." /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) - системы, все программные продукты которой известны, оттестированы на совместимость друг с другом и отражены в совместных стартовых сценариях вроде /etc/rc.network. Еще одно, ныне утерянное преимущество линейной схемы - на медленных старых машинах она работала существенно быстрее, чем схема .d. В самом деле, при вызове из rc множества других сценариев было бы непоправимой ошибкой выполнять их тем же интерпретатором, что и rc (т. е. использовать команду " ."): синтаксическая ошибка в любом из них приведет к сбою самого rc, и процедура начальной загрузки аварийно остановится. Значит, для интерпретации каждого управляющего сценария нужно запустить собственную копию shell - 30 лет назад эта операция требовала очень много системного времени: новый процесс, дополнительная оперативная память, открытие нового файла...

Сейчас эти различия уже неактуальны: размер однотипных программ растет линейно (если, конечно, не раздувать объем кода искусственно), а производительность компьютеров - экспоненциально (см. [ 15 ] ), так что сами стартовые сценарии и упомянутые системные вызовы работают уже слишком быстро по сравнению с обработкой пользовательских данных. Дело в том, что объем хранилищ данных растет вместе с быстродействием компьютера: наибольший размер хранилища данных зависит от того, как долго пользователь согласен ждать окончания операции выборки. Поэтому, например, скорость работы команды 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.