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

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