Текст книги "Внутреннее устройство Linux"

Автор книги: Брайан Уорд

сообщить о нарушении

Текущая страница: 10 (всего у книги 30 страниц) [доступный отрывок для чтения: 11 страниц]

# grub-install —boot-directory=/mnt/boot /dev/sdc

Установка загрузчика GRUB в интерфейсе UEFI

Предполагается, что установка в интерфейсе UEFI происходит проще, поскольку вам потребуется лишь скопировать загрузчик системы на место. Помимо этого, необходимо также «известить» прошивку о загрузчике системы с помощью команды efibootmgr. Если команда grub-install доступна, она выполнит это, поэтому теоретически для установки загрузчика в раздел с интерфейсом UEFI вам необходимо запустить такую команду:

# grub-install —efi-directory=efi_dir –bootloader-id=name

Здесь параметр efi_dir задает расположение каталога UEFI, как он виден вашей системе (обычно это /boot/efi/efi, поскольку раздел UEFI часто монтируется в точке /boot/efi), а параметр name является идентификатором загрузчика системы, как рассказано в разделе 5.8.2. Загрузка в интерфейсе UEFI.

К сожалению, при установке загрузчика в интерфейсе UEFI может возникнуть множество проблем. Например, если вы устанавливаете его на диск, который в итоге окажется в другой системе, вы должны выяснить, как объявить данный загрузчик прошивке новой системы. Есть также отличия в процедуре установки для сменных накопителей.

Одной из самых больших проблем является безопасная загрузка интерфейса UEFI.

5.6. Проблемы с безопасной загрузкой UEFI

Одной из новейших проблем, влияющих на установку систем Linux, является функция безопасной загрузки, которая присутствует на современных компьютерах. Если она активна, то в интерфейсе UEFI данный механизм требует, чтобы загрузчики системы для возможности своего запуска были снабжены надежной цифровой подписью. Компания Microsoft требует, чтобы поставщики системы Windows 8 использовали безопасную загрузку. В результате, если вы попытаетесь установить неподписанный загрузчик системы (а в большинстве современных версий Linux это именно так), он не станет работать.

Простейший обходной путь для тех, кого не интересует Windows, состоит в отключении безопасной загрузки в настройках интерфейса EFI. Однако это не будет четко работать в системах с двухвариантной загрузкой, а также вряд ли устроит всех пользователей. По этой причине в дистрибутивах Linux предлагаются подписанные загрузчики системы. Одни представляют собой всего лишь внешний интерфейс к загрузчику GRUB, другие же предлагают полностью подписанную загрузочную последовательность (от загрузчика системы до ядра); есть также абсолютно новые загрузчики (некоторые основаны на интерфейсе efilinux).

5.7. Передача управления загрузчикам других операционных систем

Интерфейс UEFI позволяет сравнительно легко осуществить поддержку загрузки других операционных систем, поскольку в разделе EFI можно установить несколько загрузчиков системы. Тем не менее «старый стиль» MBR не поддерживает это, и даже при наличии интерфейса UEFI вам может потребоваться отдельный раздел с загрузчиком системы, который использует MBR. Можно сделать так, чтобы загрузчик GRUB загрузил и запустил другой загрузчик системы в определенном разделе диска с помощью передачи управления загрузчику.

Для передачи управления создайте новый пункт меню в конфигурации загрузчика GRUB (используя один из методов пункта «Обзор файла Grub.cfg» в подразделе 5.5.2). Вот пример для установленной в третьем разделе диска Windows:

menuentry "Windows" {

       insmod chain

       insmod ntfs

       set root=(hd0,3)

       chainloader +1

}

Параметр +1 в строке chainloader сообщает загрузчику, чтобы он загрузил то, что находится в первом секторе раздела. Можно также напрямую указать загрузку файла, использовав строку, подобную приведенной ниже для загрузчика io.sys системы MS-DOS:

menuentry "DOS" {

       insmod chain

       insmod fat

       set root=(hd0,3)

       chainloader /io.sys

}

5.8. Детали загрузчика системы

Теперь мы рассмотрим некоторые внутренние части загрузчика системы. Можете спокойно переходить к следующей главе, если данный материал вам неинтересен.

Чтобы понять, как работают загрузчики системы, подобные GRUB, сначала исследуем, как загружается персональный компьютер, когда вы его включаете. Вследствие неадекватности традиционных механизмов загрузки ПК есть несколько вариантов, однако основных схем две: MBR и UEFI.

5.8.1. Загрузка с применением таблицы MBR

В дополнение к информации о разделе, которая описана в разделе 4.1, таблица MBR (Master Boot Record, главная загрузочная запись) содержит небольшую область (441 байт), которую система BIOS выполняет по завершении проверки POST (Power-On Self-Test, самотестирование при включении питания). К сожалению, эта область слишком мала, чтобы разместить загрузчик системы, поэтому необходимо дополнительное пространство. В результате возникает то, что иногда называют многоэтапным загрузчиком системы. В этом случае начальный фрагмент кода в таблице MBR не делает ничего, кроме загрузки оставшейся части кода загрузчика системы. Эти фрагменты загрузчика обычно помещаются в область между таблицей MBR и первым разделом диска.

Это не слишком безопасно, поскольку данный код может перезаписать кто угодно. Однако большинство загрузчиков, включая версии GRUB, поступают именно так. Более того, эта схема не будет работать для диска с разделами GPT при использовании системы BIOS для загрузки, поскольку информация таблицы GPT размещена в области после таблицы MBR. Таблица GPT не затрагивает традиционную таблицу MBR в целях обратной совместимости.

Обходной путь для таблицы GPT состоит в создании небольшого загрузочного раздела BIOS со специальным идентификатором UUID, чтобы предоставить место для размещения полного кода загрузчика системы. Однако таблица GPT обычно используется с интерфейсом UEFI, а не с традиционной системой BIOS, это приводит нас к схеме загрузки с применением интерфейса UEFI.

5.8.2. Загрузка с применением интерфейса UEFI

Производители компьютеров и компании, занимающиеся разработкой ПО, осознали, что традиционная система BIOS является весьма ограниченной, поэтому они решили разработать замену под названием расширенный интерфейс прошивки (EFI, Extensible Firmware Interface). Этому интерфейсу потребовалось некоторое время, чтобы прижиться в ПК, а теперь он достаточно распространен. Текущим стандартом является унифицированный интерфейс UEFI (Unified EFI), содержащий такие функции, как встроенная оболочка, а также возможность чтения таблиц разделов и навигация по файловым системам. Схема GPT является частью стандарта UEFI.

Загрузка систем с интерфейсом UEFI происходит совершенно иначе, и понять ее гораздо проще. Вместо исполняемого кода загрузки, который расположен вне файловой системы, здесь всегда присутствует специальная файловая система под названием «системный раздел EFI» (ESP, EFI System Partition), содержащий каталог efi. Каждый загрузчик системы обладает идентификатором и соответствующим подкаталогом, например efi/microsoft, efi/apple или efi/grub. Файл загрузчика системы снабжен расширением .efi и располагается в одном из таких подкаталогов вместе с дополнительными файлами поддержки.

примечание

Раздел ESP отличается от загрузочного раздела BIOS, описанного в подразделе 5.8.1, и обладает другим идентификатором UUID.

Однако есть здесь некоторая тонкость: нельзя просто взять и поместить код старого загрузчика системы в раздел ESP, поскольку этот код был написан для интерфейса BIOS. Вместо этого вы должны предоставить загрузчик системы, написанный для интерфейса UEFI. Например, при использовании загрузчика GRUB вы должны установить UEFI-версию загрузчика GRUB, а не BIOS-версию. Помимо этого, следует «известить» прошивку о новых загрузчиках системы.

Как отмечалось в разделе 5.6, есть сложности с «безопасной загрузкой».

5.8.3. Как работает загрузчик GRUB

Подведем итог нашему обзору загрузчика GRUB, рассмотрев то, как он выполняет свою работу.

1. Система BIOS или прошивка ПК инициализирует аппаратные средства и выполняет поиск кода загрузки в устройствах хранения в указанной загрузочной последовательности.

2. Обнаружив код загрузки, система BIOS или прошивка загружают и исполняют его. Именно здесь в дело вступает загрузчик GRUB.

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 такое состояние компьютера называется уровнем запуска и обозначается числом от 0 до 6. Основную часть времени система проводит на одном уровне запуска, но когда вы выключаете компьютер, команда 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 type unit

Порядок следования

Ни один из вариантов синтаксиса, который вы видели, не определяет явным образом порядок следования модулей. По умолчанию активизация модуля с зависимостью Requires или Wants ведет к тому, что команда systemd активизирует одновременно все такие зависимости в качестве первого модуля. Это оптимально, поскольку необходимо запустить по возможности максимальное количество служб, причем максимально быстро, чтобы сократить время загрузки системы. Однако бывают ситуации, когда один модуль должен быть запущен после другого. Например, в системе, которая изображена на рис. 6.1, настроен запуск модуля default.target после модуля multi-user.service (этот порядок следования не отображен на иллюстрации).

Чтобы активизировать модули в определенном порядке, можно использовать следующие модификаторы зависимостей.

• Before. Текущий модуль будет активизирован до указанного модуля или модулей. Например, если в модуле foo.target будет инструкция Before=bar.target, команда systemd активизирует модуль foo.target перед модулем bar.target.

• After. Текущий модуль будет активизирован после перечисленного модуля или модулей.

Условные зависимости

Некоторые ключевые слова для условных зависимостей применяются в различных состояниях операционной системы вместо модулей команды systemd. Например:

• ConditionPathExists=p: – истинно, если путь (файла) p существует в системе;

• ConditionPathIsDirectory=p: – истинно, если p является каталогом;

• ConditionFileNotEmpty=p: – истинно, если p является файлом ненулевой длины.

Если условная зависимость в модуле не является истинной, когда команда systemd пытается активизировать данный модуль, то этот модуль не активизируется. Но это распространяется только на модуль, в котором есть условие. Следовательно, если вы активизируете модуль, в котором есть условная зависимость, а также некоторые другие зависимости этого модуля, команда systemd попытается активизировать их, не обращая внимания на истинность или ложность условия.

Другие зависимости являются главным образом вариантами перечисленных. Например, зависимость RequiresOverridable похожа на зависимость Requires, если режим работы нормальный, но она начинает вести себя подобно зависимости Wants, если модуль активизирован вручную. Полный перечень зависимостей можно увидеть на странице systemd.unit(5) руководства.

После того как вы увидели несколько фрагментов конфигурации команды systemd, посмотрим на реальные файлы модулей и на то, как они работают.

6.4.3. Конфигурация команды systemd

Файлы конфигурации команды systemd рассеяны по множеству каталогов системы, так что вы, как правило, не сможете найти файлы для всех модулей в одном месте. Однако имеется два основных каталога для конфигурации команды systemd: каталог системных модулей (настраивается глобально, обычно это /usr/lib/systemd/system) и каталог системной конфигурации (локальные определения, обычно это /etc/systemd/system).

Во избежание недоразумений следуйте правилу: не вносите изменения в каталог модулей, поскольку ваша система позаботится об этом за вас. Локальные изменения вносите в каталог системной конфигурации. Итак, если вам будет предоставлен выбор между изменениями чего-либо в каталогах /usr и /etc, всегда изменяйте каталог /etc.

примечание

Можно выяснить текущий путь поиска для команды systemd (включая приоритет) с помощью такой команды:

# systemctl -p UnitPath show

Однако этот частный параметр исходит из третьего источника – настроек pkg-config. Чтобы увидеть каталоги системных модулей и конфигурации вашей системы, используйте следующие команды:

$ pkg-config systemd –variable=systemdsystemunitdir

$ pkg-config systemd —variable=systemdsystemconfdir

Файлы модулей

Происхождение файлов модулей восходит к спецификации записей XDG (для файлов с расширением .desktop, которые очень похожи на файлы с расширением .ini в системах Microsoft), в которых названия секций заключены в скобки ([]), а в каждой из секций указаны переменные с присвоенными им значениями (параметрами).

Рассмотрим как пример файл модуля media.mount из каталога /usr/lib/systemd/system, который является стандартным для версии Fedora. Этот файл представляет файловую систему tmpfs, каталог /media выступает в роли контейнера для монтирования съемных носителей.

[Unit]

Description=Media Directory

Before=local-fs.target

[Mount]

What=tmpfs

Where=/media

Type=tmpfs

Options=mode=755,nosuid,nodev,noexec

Здесь присутствуют две секции. Секция [Unit] сообщает некоторые подробности о модуле и содержит описание и сведения о зависимости. В частности, этот модуль настроен так, чтобы его активизация происходила до модуля local-fs.target.

Секция [Mount] описывает данный модуль в роли модуля монтирования, а также сообщает детали о точке монтирования, типе файловой системы и параметрах монтирования, описанных в подразделе 4.2.6. Переменная What= идентифицирует устройство или идентификатор UUID устройства, предназначенного для монтирования. Здесь ему присвоено значение tmpfs, поскольку у этой файловой системы нет устройства. Полный перечень параметров модуля монтирования можно увидеть на странице systemd.mount(5) руководства.

Многие другие файлы конфигурации модулей такие же простые. Например, файл модуля службы sshd.service задействует безопасный вход в оболочку:

[Unit]

Description=OpenSSH server daemon

After=syslog.target network.target auditd.service

[Service]

EnvironmentFile=/etc/sysconfig/sshd

ExecStartPre=/usr/sbin/sshd-keygen