Помоги проекту - поделись книгой:
3. Загружается ядро загрузчика GRUB.
4. Происходит инициализация ядра. К этому моменту загрузчик GRUB получает доступ к дискам и файловым системам.
5. Загрузчик GRUB идентифицирует свой загрузочный раздел и загружает в него конфигурацию.
6. Загрузчик GRUB дает пользователю возможность изменить конфигурацию.
7. По истечении времени ожидания или после ответных действий пользователя загрузчик GRUB выполняет конфигурирование (последовательность команд, о которых говорилось в подразделе 5.5.2).
8. В процессе конфигурирования загрузчик GRUB может загрузить дополнительный код (модули) в загрузочный раздел.
9. Загрузчик GRUB исполняет команду boot, чтобы загрузить и исполнить ядро, как определено командой linux в конфигурации.
Шаги 3 и 4 в приведенной схеме, когда загружается ядро загрузчика GRUB, могут оказаться сложнее вследствие повторяющейся неадекватности традиционных механизмов загрузки ПК. Самый главный вопрос: где расположено ядро загрузчика GRUB? Существует три основные возможности:
• по частям размещено в таблице MBR и перед началом первого раздела;
• в обычном разделе;
• в специальном загрузочном разделе: загрузочном разделе GPT, системном разделе EFI (ESP) или еще где-либо.
Во всех случаях, исключая наличие раздела ESP, система BIOS загружает 512 байт из таблицы MBR, и именно здесь начинается загрузчик GRUB. Этот небольшой фрагмент (отщепленный от файла boot.img из каталога загрузчика GRUB) еще не является ядром, но он содержит исходную точку для ядра, с которой начинается его загрузка.
Однако при наличии раздела ESP ядро загрузчика GRUB присутствует здесь в виде файла. Прошивка может просмотреть раздел ESP и напрямую исполнить ядро загрузчика GRUB или загрузчика любой другой операционной системы, размещенного здесь.
Для большинства систем эта картина не является полной. Загрузчику системы может также понадобиться загрузить начальный образ файловой системы оперативной памяти до загрузки и исполнения ядра. Именно это определяет конфигурационный параметр initrd в разделе 6.8. Прежде чем вы узнаете о начальной файловой системе оперативной памяти, вам необходимо изучить запуск пространства пользователя. Именно с этого начинается следующая глава.
6. Как запускается пространство пользователя
Момент, когда ядро запускает первый процесс из пространства пользователя, init, важен не только потому, что именно сейчас оперативная память и центральный процессор окончательно готовы к нормальной работе, но и потому, что здесь вы можете увидеть, каким образом остальная часть системы выстраивается как целое. До этого момента ядро исполняет хорошо контролируемую последовательность действий, которая определена сравнительно малым количеством разработчиков ПО. Пространство пользователя в гораздо большей степени обладает модульной структурой. Здесь намного проще увидеть, что происходит в пространстве пользователя при его запуске и работе. Смелым пользователям также довольно просто изменить настройки запуска пространства пользователя, поскольку для этого не требуются навыки программирования на низком уровне.
В общих чертах, пространство пользователя запускается следующим образом.
1. Команда init.
2. Важнейшие низкоуровневые службы, такие как udevd и syslogd.
3. Сетевая конфигурация.
4. Службы среднего и высокого уровня (крон, печать и т. д.).
5. Приглашение ко входу в систему, пользовательский интерфейс и другие приложения высокого уровня.
6.1. Знакомство с командой init
Команда init — это команда из пространства пользователя, подобная любой другой команде системы Linux. Ее можно найти в каталоге /sbin вместе с другими системными исполняемыми файлами. Основное назначение этой команды — запуск и останов важнейших служебных процессов системы, хотя новые версии обладают дополнительными возможностями.
В дистрибутивах Linux существует три основные реализации команды init.
• System V init. Обычная последовательная команда init (Sys V, обычно произносится sys-five). Версия Red Hat Enterprise Linux и некоторые другие используют этот вариант.
systemd. Набирающий силу стандарт команды init. Во многих дистрибутивах осуществлен переход на команду systemd, а в тех, где это еще не сделано, такой переход планируется.
Upstart. Команда init для версий Ubuntu. Тем не менее к моменту написания книги в Ubuntu также запланирован переход на команду systemd.
Существуют также различные другие версии команды init, в особенности на встроенных платформах. Например, платформа Android обладает собственной командой init. В BSD также есть собственная версия команды init, но вряд ли вы встретите ее на современном компьютере с Linux. В некоторых дистрибутивах конфигурация команды System V init изменена, чтобы напоминать стиль BSD.
Различные реализации команды init существуют потому, что команда System V init и более ранние версии основаны на последовательности, в которой в один момент времени выполняется только одна задача запуска. Такая схема довольно легко позволяет разбираться с зависимыми процессами, однако производительность при этом не впечатляюще хороша, поскольку две части последовательности загрузки обычно не могут работать одновременно. Еще одним ограничением является возможность запуска лишь небольшого набора служб, определенных в последовательности загрузки: когда вы подключаете новое аппаратное средство или вам необходима еще не запущенная служба, не существует стандартизованного способа координации новых компонентов с командой init. Команды systemd и Upstart пытаются улучшить производительность, позволяя параллельный запуск нескольких служб, тем самым ускоряя процесс загрузки. Однако реализованы они совершенно по-разному.
• Команда systemd является ориентированной на цель. Вы определяете цель, которую необходимо достичь, а также зависящие от нее процессы и момент, когда цель должна быть достигнута. Команда systemd удовлетворяет все зависящие процессы и выполняет цель. Эта команда может также отложить запуск какой-либо службы, если она не является абсолютно необходимой.
• Команда Upstart выполняет ответную реакцию. Она реагирует на события и, основываясь на них, запускает задачи, которые, в свою очередь, порождают новые события, побуждающие команду Upstart запускать дополнительные задачи, и т. д.
Команды systemd и Upstart предлагают также более развитые способы запуска и отслеживания служб. В традиционных вариантах команды init ожидается, что демоны служб запускаются сами из сценариев. Сценарий запускает команду-демон, которая отделяется от сценария и работает автономно. Чтобы выяснить идентификатор PID для демона службы, необходимо использовать команду ps или какой-либо дугой способ, специфичный для данной службы. И напротив, команды Upstart и systemd могут изначально управлять отдельными демонами служб, предоставляя пользователю больше возможностей и точное понимание происходящего в системе.
Поскольку новые варианты команды init не завязаны на сценариях, конфигурирование служб для них также производится проще. В частности, сценарии команды System V init обычно содержат множество похожих команд, предназначенных для запуска, останова и повторного запуска служб. Подобная избыточность не понадобится вам в командах systemd и Upstart, которые позволяют сконцентрироваться на самих службах, а не на их сценариях.
Наконец, обе команды, systemd и Upstart, предлагают некоторую степень использования служб по запросу. Вместо того чтобы запускать все службы, которые могут понадобиться при загрузке системы (как сделала бы команда System V init), эти команды запускают службы только по мере необходимости. Эта идея не нова, она использована в традиционном демоне inetd, однако новые реализации являются более развитыми.
Команды systemd и Upstart предлагают некоторую долю обратной совместимости с командой System V. Например, обе поддерживают концепцию уровней запуска.
6.2. Уровни запуска команды System V
В каждый конкретный момент времени в системе Linux задействован некоторый набор процессов (таких как crond и udevd). Для команды System V init такое состояние компьютера называется
Узнать уровень запуска вашей системы можно с помощью команды who — r. Система, в которой запущена команда Upstart, ответит чем-либо подобным:
$ who — r
run-level 2 2015-09-06 08:37
Этот результат сообщает нам о том, что текущий уровень запуска равен 2. Указаны также дата и время перехода на этот уровень запуска.
Уровни запуска служат различным целям, наиболее часто они используются для различения состояний запуска и выключения системы, режима одиночного пользователя и консоли. Так, например, системы семейства Fedora традиционно используют уровни запуска с 2 по 4 для текстовой консоли; уровень запуска 5 означает, что будет загружен графический интерфейс пользователя для входа в систему.
Однако уровни запуска постепенно уходят в прошлое. Несмотря на то что все три версии команды init, о которых рассказано в этой книге, поддерживают эти уровни, команды systemd и Upstart считают уровни запуска устаревшими для использования в качестве определяющих состояний системы. Для команд systemd и Upstart уровни запуска существуют главным образом для запуска служб, которые поддерживают только сценарии версии System V init. К тому же реализация уровней настолько различна, что даже если вы хорошо знакомы с одним из типов команды init, то это совсем не значит, что вы знаете, как работать с другим.
6.3. Определяем тип команды init
Прежде чем продолжить, вам необходимо определить, какая версия команды init используется в вашей системе. Если вы не вполне уверены, выполните следующие проверки.
• Если в вашей системе есть каталоги /usr/lib/systemd и /etc/systemd, то вы пользуетесь командой systemd. Переходите к разделу 6.4.
• Если каталог /etc/init содержит несколько файлов с расширением. conf, вы, вероятно, работаете с командой Upstart (за исключением Debian 7: в этом случае у вас, видиммо, команда System V init). Переходите к разделу 6.5.
• Если ни один из приведенных вариантов не подходит, однако есть файл /etc/inittab, вероятно, вы используете команду System V init. Переходите к разделу 6.6.
Если в вашей системе установлено руководство, просмотр страницы init(8) должен помочь вам при определении версии команды init.
6.4. Команда systemd
Версия systemd команды init — одна из новейших реализаций команды init для Linux. Помимо работы с обычным процессом загрузки, команда systemd призвана также включить некоторые стандартные службы Unix, такие как cron и inetd. В этом можно заметить некоторое влияние команды launchd компьютеров Apple. Одной из ее самых существенных функций является возможность отложить запуск служб и некоторых функций операционной системы до тех пор, пока они не понадобятся.
У команды systemd так много функций, что довольно трудно понять, с чего начать изучение основ. В общих чертах опишу, что происходит, когда во время загрузки системы запускается команда systemd.
1. Команда systemd загружает свою конфигурацию.
2. Команда systemd определяет цель загрузки, которая обычно называется default.target.
3. Команда systemd определяет все зависимости для цели загрузки по умолчанию, зависимости зависимостей и т. д.
4. Команда systemd активизирует зависимые процессы и цель загрузки.
5. После загрузки команда systemd может реагировать на системные события (такие как uevents) и активизировать дополнительные компоненты.
При запуске служб команда systemd не придерживается жесткой последовательности. Как и у других современных версий команды init, процесс загрузки с помощью команды systemd довольно гибок. В большинстве вариантов конфигурации команды systemd намеренно пытаются избегать какой бы то ни было стартовой последовательности, предпочитая использовать другие методы для устранения жестких зависимостей.
6.4.1. Модули и типы модулей
Одним из самых интересных свойств команды systemd является то, что она не только управляет процессами и службами, но способна также монтировать файловые системы, отслеживать сетевые сокеты, запускать таймеры и многое другое. Каждый тип таких возможностей называется
Вместо того чтобы описывать все типы модулей (вы найдете их на странице руководства systemd(1)), рассмотрим лишь некоторые из них, которые выполняют задачи запуска в любой системе Unix.
• Модули служб. Контролируют традиционные демоны служб в системе Unix.
Модули монтирования. Контролируют присоединение файловых систем.
Целевые модули. Контролируют другие модули, как правило группируя их.
По умолчанию целью загрузки обычно является целевой модуль, который группирует несколько служб и монтирует модули в качестве зависимостей. В результате довольно легко получить частичное представление о том, что происходит при загрузке системы. Можно даже составить дерево зависимостей с помощью команды systemctl dot. Вы обнаружите, что это дерево достаточно обширное, поскольку многие модули не запускаются по умолчанию.
На рис. 6.1 приведена часть дерева зависимостей для модуля default.target, который можно найти в системе Fedora. При активизации этого модуля все расположенные под ним модули также активизируются.
Рис. 6.1. Дерево зависимостей модуля
6.4.2. Зависимости команды systemd
Зависимости при загрузке системы и ее работе гораздо сложнее, чем могут показаться на первый взгляд, поскольку жесткие зависимости не допускают изменений. Например, вы решили, что приглашение ко входу в систему будет отображаться после запуска сервера базы данных, поэтому вы определяете зависимость приглашения от сервера базы данных. Однако если с сервером базы данных случится сбой, то в результате указанной зависимости приглашение ко входу в систему также не появится, и вы не сможете даже войти в систему, чтобы исправить ошибку.
Задачи запуска системы Unix довольно терпимо относятся к ошибкам и зачастую сбои в задачах не вызывают серьезных проблем в стандартных службах. Например, если диск с данными для системы будет удален, но запись о нем в таблице /etc/fstab останется, то начальное монтирование файловой системы не осуществится. Однако такой сбой обычно не вызовет серьезных последствий в стандартной работе системы.
Чтобы приспособиться к требованиям гибкости и устойчивости к сбоям, команда systemd предлагает огромное количество типов и стилей зависимостей. Обозначим их по ключевым словам синтаксиса, но подробно этот синтаксис будет рассмотрен в подразделе 6.4.3. Посмотрим сначала на главные типы.
• Requires. Жесткие зависимости. При активизации модуля с зависимостью Requires команда systemd пытается активизировать модуль зависимости. Если модуль зависимости дает сбой, то команда systemd деактивизирует зависимый модуль.
Wants. Зависимости, предназначенные только для активизации. Во время активизации какого-либо модуля команда systemd активизирует его Wants-зависимости, но не обращает внимания, если они дают сбой.
Requisite. Модули, которые уже должны быть активными. Перед активизацией модуля с зависимостью Requisite команда systemd сначала проверяет состояние зависимости. Если такая зависимость еще не была активизирована, команда systemd дает сбой при активизации модуля с этой зависимостью.
Conflicts. Противоположные зависимости. При активизации модуля с зависимостью Conflict команда systemd автоматически деактивизирует такую зависимость, если она активна. Одновременная активизация двух конфликтующих модулей вызовет сбой.
примечание
Тип зависимостей Wants особенно важен, поскольку он не распространяет ошибки на другие модули. В документации к команде systemd заявлено, что именно таким образом следует по возможности определять зависимости. Это позволит создать гораздо более устойчивую систему, подобную той, которая применяет традиционную команду init.
Зависимости могут быть также подключены «реверсивно». Например, чтобы добавить модуль А в качестве Wants-зависимости для модуля Б, не обязательно добавлять зависимость Wants в конфигурацию модуля Б. Вместо этого можно указать его как WantedBy-зависимость в конфигурации модуля А. То же самое верно и для зависимости RequiredBy. Конфигурация (а также результат) зависимости “By” немного сложнее, чем простое редактирование файла с настройками (см. пункт «Подключение модулей и секция [Install]» в подразделе 6.4.3).
Увидеть зависимости какого-либо модуля можно с помощью команды systemctl. С ее помощью можно также указать тип зависимости, например Wants или Requires:
# systemctl show — p
Порядок следования
Ни один из вариантов синтаксиса, который вы видели, не определяет явным образом порядок следования модулей. По умолчанию активизация модуля с зависимостью Requires или Wants ведет к тому, что команда systemd активизирует одновременно все такие зависимости в качестве первого модуля. Это оптимально, поскольку необходимо запустить по возможности максимальное количество служб, причем максимально быстро, чтобы сократить время загрузки системы. Однако бывают ситуации, когда один модуль должен быть запущен после другого. Например, в системе, которая изображена на рис. 6.1, настроен запуск модуля default.target после модуля multi-user.service (этот порядок следования не отображен на иллюстрации).
Чтобы активизировать модули в определенном порядке, можно использовать следующие модификаторы зависимостей.
• Before. Текущий модуль будет активизирован до указанного модуля или модулей. Например, если в модуле foo.target будет инструкция Before=bar.target, команда systemd активизирует модуль foo.target перед модулем bar.target.
After. Текущий модуль будет активизирован после перечисленного модуля или модулей.
Условные зависимости
Некоторые ключевые слова для условных зависимостей применяются в различных состояниях операционной системы вместо модулей команды systemd. Например:
• ConditionPathExists=
• ConditionPathIsDirectory=
Поделиться книгой: