Внутреннее устройство Linux

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

ExecStart=/usr/sbin/sshd — D $OPTIONS

ExecReload=/bin/kill — HUP $MAINPID

[Install]

WantedBy=multi-user.target

Поскольку эта цель является службой, в секции [Service] вы найдете подробности, сообщающие о том, как подготовить, запустить и перезагрузить данную службу. Полный перечень можно увидеть на странице systemd.service(5) (а также на странице systemd.exec(5)) руководства. Отслеживание процессов будет рассмотрено в подразделе 6.4.6.

Подключение модулей и секция [Install]

Секция [Install] в файле модуля sshd.service важна, поскольку она помогает понять, как использовать параметры зависимостей WantedBy и RequiredBy в команде systemd. Фактически это является механизмом подключения модулей без изменения каких-либо файлов конфигурации. Во время нормальной работы команда systemd игнорирует секцию [Install]. Однако представьте ситуацию, когда в вашей системе отключена служба sshd.service и вы желаете ее включить. Когда вы включаете модуль, команда systemd читает секцию [Install]; в данном случае включение модуля sshd.service приводит к тому, что команда systemd видит зависимость WantedBy для модуля multi-user.target. В ответ на это команда systemd следующим образом создает в каталоге системной конфигурации символическую ссылку на модуль sshd.service:

ln — s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.

target.wants/sshd.service'

Обратите внимание на то, что символическая ссылка помещена в подкаталог, соответствующий зависимому модулю (в данном случае это multi-user.target).

Секция [Install] обычно отвечает за каталоги. wants и. requires в каталоге системной конфигурации (/etc/systemd/system). Тем не менее каталоги. wants присутствуют также в каталоге конфигурации модулей (/usr/lib/systemd/system), и вы можете также добавлять ссылки, которые не соответствуют секциям [Install], в файлы модулей. Такие вносимые вручную дополнения являются простым способом добавить зависимость, не изменяя файл модуля, который может быть перезаписан в будущем (например, во время обновления ПО).

примечание

Подключение модуля отличается от его активизации. При подключении модуля вы указываете его в конфигурации команды systemd, внося полупостоянные изменения, которые сохраняются после перезагрузки системы. Однако не обязательно каждый раз явным образом подключать модуль. Если в файле модуля есть секция [Install], вы должны подключить его с помощью инструкции systemctl enable; в противном случае достаточно уже одного наличия такого файла для подключения модуля. Когда вы активизируете модуль с помощью systemctl start, вы просто задействуете его в текущем рабочем окружении. Кроме того, подключение модуля не активизирует его.

Переменные и спецификаторы

Файл модуля sshd.service демонстрирует также применение переменных, а именно переменных окружения $OPTIONS и $MAINPID, которые переданы командой systemd. Значения переменной $OPTIONS являются параметрами, которые можно передать команде sshd при активизации данного модуля командой systemctl, а значение переменной $MAINPID — это отслеживаемый процесс службы (см. подраздел 6.4.6).

Спецификатор — это еще одно похожее на переменную средство, которое часто можно увидеть в файлах модулей. Спецификаторы начинаются с символа процента (%). Например, спецификатор %n представляет имя текущего модуля, а спецификатор %H — имя текущего хоста.

примечание

Имя модуля может содержать некоторые интересные спецификаторы. Можно параметризовать единичный файл модуля, чтобы породить несколько копий какой-либо службы, например процессов getty, работающих в терминалах tty1, tty2 и т. д. Чтобы использовать эти спецификаторы, добавьте символ @ в конец имени модуля. Для процесса getty создайте файл модуля с именем getty@.service, который позволит вам обращаться к таким модулям, как getty@tty1 и getty@tty2. Все, что следует за символом @, называется экземпляром, и при обработке файла модуля команда systemd развертывает спецификатор %I в имя экземпляра. Увидеть это в действии можно на файлах getty@.service, которые входят в большинство систем, использующих команду systemd.

6.4.4. Работа команды systemd

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

Наиболее существенные основные команды имеют дело с получением информации о модулях. Например, чтобы увидеть список активных модулей в вашей системе, воспользуйтесь командой list-units. На самом деле эта команда работает по умолчанию при запуске команды systemctl, поэтому часть list-units не нужна:

$ systemctl list-units

Формат вывода типичен для информационных команд Unix. Так, например, выглядит заголовок и строка для модуля media.mount:

UNIT LOAD ACTIVE SUB JOB DESCRIPTION

media.mount loaded active mounted Media Directory

Эта команда выводит много сведений, поскольку в типичной системе большое количество активных модулей, но даже при этом список сокращен, поскольку команда systemctl обрезает все действительно длинные названия модулей. Чтобы увидеть полные имена модулей, используйте параметр — full, а чтобы увидеть все модули (а не только активные) — параметр — all.

Чрезвычайно полезной функцией команды systemctl является получение статуса модуля. Вот, например, типичная команда запроса статуса и результат ее работы:

$ systemctl status media.mount

media.mount — Media Directory

Loaded: loaded (/usr/lib/systemd/system/media.mount; static)

Active: active (mounted) since Wed, 13 May 2015 11:14:55 -0800;

37min ago

Where: /media

What: tmpfs

Process: 331 ExecMount=/bin/mount tmpfs /media — t tmpfs — o

mode=755,nosuid,nodev,noexec (code=exited, status=0/SUCCESS)

CGroup: name=systemd:/system/media.mount

Обратите внимание на то, что информации здесь гораздо больше, чем можно увидеть в любой традиционной системе init. Вы узнаете не только статус модуля, но также и точное название команды, использованной при его монтировании, его идентификатор PID, а также его конечный статус.

Одним из самых интересных фрагментов этого вывода является имя группы управления. В приведенном примере группа управления не содержит никакой информации, кроме имени systemd:/system/media.mount, поскольку процессы модуля уже остановлены. Однако, если вы запросите статус модуля службы, например NetworkManager.service, вы увидите также дерево процессов группы управления. Можно увидеть группы управления без сопутствующего статуса модуля с помощью команды systemd-cgls. О группах управления вы узнаете больше из подраздела 6.4.6.

Команда статуса отображает также последнюю информацию из журнала модуля (этот журнал записывает диагностическую информацию для каждого модуля).

Полный журнал модуля можно увидеть с помощью такой команды:

$ journalctl _SYSTEMD_UNIT=unit

Синтаксис немного странный, поскольку команда journalctl способна получать доступ не только к модулю systemd.

Для активизации, деактивизации и перезапуска модулей используйте команды systemd start, stop и restart. Однако если вы изменили файл конфигурации модуля, можно перезагрузить такой файл одним из двух способов:

• systemctl reload unit — перезагружает только конфигурацию модуля unit;

• systemctl daemon-reload — перезагружает конфигурацию всех модулей.

Запросы на активизацию, повторную активизацию и перезапуск модулей известны как задания для команды systemd, они являются, по сути, изменениями состояния модулей. Узнать о текущих заданиях в системе можно с помощью команды:

$ systemctl list-jobs

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

JOB UNIT TYPE STATE

1 graphical.target start waiting

2 multi-user.target start waiting

71 systemd-…nlevel.service start waiting

75 sm-client.service start waiting

76 sendmail.service start running

120 systemd-…ead-done.timer start waiting

В данном случае задание 76, запуск модуля sendmail.service, действительно происходит довольно долго. Остальные перечисленные задания находятся в ждущем режиме, скорее всего, потому, что все они ждут задание 76. Когда служба sendmail.service завершит запуск и станет полностью активна, задание 76 и все остальные задания также будут завершены, а список заданий станет пустым.

примечание

Термин задание может сбивать с толку еще и потому, что другая версия команды init, Upstart, описанная в данной главе, использует слово «задание» (в общих чертах) применительно к тому, что команда systemd называет модулем. Важно помнить о том, что, если задание команды systemd, связанное с каким-либо модулем, будет завершено, сам модуль останется активным и в дальнейшем работающим, особенно в случае модулей служб.

Обратитесь к разделу 6.7, чтобы узнать о том, как выключать и перезапускать систему.

6.4.5. Добавление модулей в команду systemd

Добавление модулей заключается в создании, активизации и возможном редактировании файлов модулей. Обычно пользовательские файлы модулей следует помещать в каталог системной конфигурации /etc/systemd/system, чтобы не перепутать их с чем-либо, входящим в состав вашей версии системы, и чтобы система не перезаписала их при обновлении.

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

1. Создайте файл модуля с именем test1.target:

[Unit]

Description=test 1

2. Создайте файл test2.target с зависимостью от файла test1.target:

[Unit]

Description=test 2

Wants=test1.target

3. Активизируйте модуль test2.target (помня о том, что зависимость в файле test2.target вынуждает команду systemd активизировать при этом и модуль test1.target):

# systemctl start test2.target

4. Убедитесь в том, что оба модуля активны:

# systemctl status test1.target test2.target

test1.target — test 1

Loaded: loaded (/etc/systemd/system/test1.target; static)

Active: active since Thu, 12 Nov 2015 15:42:34 -0800; 10s ago

test2.target — test 2

Loaded: loaded (/etc/systemd/system/test2.target; static)

Active: active since Thu, 12 Nov 2015 15:42:34 -0800; 10s ago

примечание

Если в файле модуля есть секция [Install], подключите модуль до его активизации:

# systemctl enable unit

Опробуйте это на предыдущем примере. Удалите зависимость из файла test2.target и добавьте секцию [Install] в файл test1.target, содержащую строку WantedBy=test2.target.

Удаление модулей. Чтобы удалить модуль, выполните следующее.

1. Если необходимо, деактивизируйте модуль:

# systemctl stop unit

2. Если в модуле есть секция [Install], отключите модуль, чтобы удалить все зависимые символические ссылки:

# systemctl disable unit

3. Удалите файл модуля, если желаете.

6.4.6. Отслеживание процессов и синхронизация в команде systemd

Команде systemd необходимы разумное количество информации и степень контроля над каждым запускаемым процессом. Основная проблема заключается в том, что службы могут быть запущены различными способами, они могут ответвляться в виде новых экземпляров и даже становиться демонами и открепляться от исходного процесса.

Чтобы свести к минимуму объем работы, который программист или администратор должен выполнить для создания работающего модуля, команда systemd использует группы управления (cgroups) — необязательную функцию ядра Linux, которая предусматривает более точное отслеживание иерархии процессов. Если вы уже работали до этого с командой Upstart, вы знаете, что необходимо проделывать небольшую дополнительную работу, чтобы выяснить, какой процесс является главным для какой-либо службы. В случае с командой systemd вам не надо беспокоиться о том, сколько раз ветвится процесс, важно лишь то, ветвится ли он. Используйте параметр Type в файле модуля для службы, чтобы указать ее поведение при запуске. Существуют два основных стиля запуска.

• Type=simple — процесс службы не ветвится.

• Type=forking — служба ветвится, и команда systemd ожидает завершения исходного процесса службы. По его завершении команда systemd предполагает, что данная служба готова.

Параметр Type=simple не учитывает тот факт, что службе может потребоваться некоторое время на настройку, а команда systemd не знает, когда запускать зависимости, для которых абсолютно необходима готовность данной службы. Один из способов справиться с этим — использовать отложенный запуск (см. подраздел 6.4.7). Однако с помощью некоторых стилей параметра Type можно указать, чтобы служба сама известила команду systemd о своей готовности:

• Type=notify — когда служба готова, она отправляет уведомление специально для команды systemd (с помощью вызова функции sd_notify());

• Type=dbus — когда служба готова, она регистрирует себя в шине D-Bus (шина рабочего стола).

Еще один вариант запуска задается параметром Type=oneshot. Здесь процесс службы завершается полностью по окончании своей работы. Для служб подобного типа непременно следует добавлять параметр RemainAfterExit=yes, чтобы команда systemd по-прежнему рассматривала данную службу как активную даже после завершения ее процессов.

И наконец, последний стиль: Type=idle. Он просто указывает команде systemd не запускать службу, пока в системе есть активные задания. Идея заключается в простом откладывании запуска службы до тех пор, пока не будут запущены другие службы, чтобы снизить нагрузку на систему или избежать перекрывания выводов различных служб. Помните: как только служба запущена, задание команды systemd, которое запустило службу, завершается.

6.4.7. Запуск по запросу и распараллеливание ресурсов в команде systemd

Одной из самых важных функций команды systemd является ее способность откладывать запуск модуля до тех пор, пока он не станет абсолютно необходим. Обычно это выглядит так.

1. Создается в обычном порядке модуль systemd (назовем его модуль А) для системной службы, которую вы собираетесь обеспечить.

2. Определяется системный ресурс (например, сетевой порт/сокет, файл или устройство), который модуль А использует для предоставления своих служб.

3. Создается еще один модуль systemd, модуль R, для предоставления данного ресурса. Эти модули являются специальными: модули сокетов, модули путей и модули устройств.

На деле это происходит следующим образом.

1. После активизации модуля R команда systemd контролирует его ресурс.

2. Если что-либо пытается получить доступ к этому ресурсу, команда systemd блокирует ресурс, а ввод в данный ресурс буферизуется.

3. Команда systemd активизирует модуль A.

4. Когда служба модуля A будет готова, она получает управление ресурсом, считывает содержимое буфера и переходит в нормальный режим работы.

Есть моменты, о которых следует позаботиться.

• Вы должны убедиться в том, что модуль ресурсов охватывает все ресурсы, предоставляемые службой. Это не составляет сложности, поскольку у большинства служб всего одна точка доступа.

• Следует убедиться в том, что модуль ресурсов прикреплен к модулю службы, которую он представляет. Это может быть сделано неявно или явно. В некоторых случаях разные параметры определяют различные способы, с их помощью команда systemd передает управление модулю службы.

• Не все серверы знают, как выполнить стыковку с модулями, которые может предоставить команда systemd.

Если вы уже знакомы с тем, как работают утилиты наподобие inetd, xinetd и automount, вы увидите много сходного. Действительно, сама концепция не нова (и в действительности команда systemd включает поддержку модулей automount). Мы перейдем к примеру модуля сокета в пункте «Пример модуля сокета и службы» далее. Однако сначала рассмотрим, какую помощь оказывают модули ресурсов при загрузке системы.

Оптимизация загрузки и вспомогательные модули

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

В основе данной схемы лежит то, что таким важным модулям служб времени загрузки, как syslog и dbus необходимо некоторое время для запуска, а многие другие модули зависят от них. Однако команда systemd способна предоставить важный для модуля ресурс (например, модуль сокета) очень быстро, после чего она может немедленно активизировать не только важный модуль, но также и любые другие модули, которые зависят от данного важного ресурса. Как только важный модуль будет готов, он забирает управление ресурсом.

На рис. 6.2 показано, как такая схема могла бы работать в традиционной системе. В данной последовательности загрузки служба E предоставляет важный ресурс R. Службы A, B и C зависят от этого ресурса и должны ожидать запуска службы E. Во время загрузки такой системе потребуется довольно много времени, чтобы добраться до запуска службы С.

Рис. 6.2. Временнáя последовательность загрузки. Указана зависимость ресурсов

На рис. 6.3 показана эквивалентная конфигурация загрузки с помощью команды systemd. Службы представлены модулями A, B и C, а новый модуль R представляет ресурс, который предоставляет модуль E. Поскольку команда systemd способна обеспечить интерфейс для модуля R, пока запускается модуль E, модули A, B, C и E могут быть все запущены одновременно. Модуль E заступает на место модуля R, когда будет готов. Интересным моментом здесь является то, что модулям A, B и C может не понадобиться явный доступ к модулю R до завершения их запуска — это демонстрирует на схеме модуль B.

примечание

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

В конечном счете, хотя вы и не создаете в данном случае запуск модуля по запросу, вы используете те же функции, которые делают его возможным. Чтобы увидеть примеры из реальной жизни, загляните в модули конфигурации syslog и D-Bus на компьютере, использующем команду systemd; очень возможно, что они будут распараллелены подобным же образом.

Пример модуля сокета и службы

Рассмотрим теперь в качестве примера простую службу сетевого эхо-запроса, которая использует модуль сокета. Этот материал достаточно сложный, и вы, вероятно, сможете понять его только после прочтения глав 9 и 10, в которых рассмотрены протокол TCP, порты, прослушивание и сокеты. По этой причине сейчас можно его пропустить и вернуться к нему позже.

Рис. 6.3. Временнáя последовательность загрузки с помощью systemd и модуля ресурсов

Идея, заложенная в эту службу, заключается в том, что, когда сетевой клиент подключается к данной службе, она повторяет все, что отправляет клиент. Модуль будет прослушивать TCP порт 22222. Мы назовем его службой эхо-запроса и начнем с модуля сокета, представленного следующим файлом модуля echo.socket:

[Unit]

Description=echo socket

[Socket]

ListenStream=22222

Accept=yes

Обратите внимание на то, что внутри файла модуля нет упоминания о том, какой модуль службы поддерживается данным сокетом. Каков же тогда соответствующий файл модуля службы?

Он называется echo@.service. Эта ссылка составлена на основе соглашения о присвоении имен: если у файла модуля службы такой же префикс, что и у файла. socket (в данном случае echo), команда systemd знает о том, что надо активизировать данный модуль службы, когда в модуле сокета возникает активность. В данном случае команда systemd создает экземпляр echo@.service, когда возникает активность сокета echo.socket.

Вот файл модуля службы echo@.service:

[Unit]

Description=echo service

[Service]

ExecStart=-/bin/cat

StandardInput=socket

примечание

Если вам не нравится неявная активизация модулей на основе префиксов или же вам необходимо создать механизм активизации между двумя модулями с разными префиксами, можно использовать вариант явного присвоения в модуле, который определяет ресурс. Применяйте, например, запись Socket=bar.socket внутри файла foo.service, чтобы модуль bar.socket предоставлял свой сокет службе foo.service.

Чтобы данная служба заработала, необходимо запустить после нее сокет echo.socket:

# systemctl start echo.socket

Теперь можно проверить эту службу, подключившись к локальному порту 22222. Когда приведенная ниже команда telnet установит соединение, наберите что-либо и нажмите клавишу Enter. Служба возвратит вам набранный текст.

$ telnet localhost 22222

Trying 127.0.0.1…

Connected to localhost.

Escape character is '^]'.

Hi there.

Hi there.

Когда захотите закончить, нажмите сочетание клавиш Ctrl+] в самой строке, а затем сочетание клавиш Ctrl+D. Чтобы остановить службу, остановите модуль сокета:

# systemctl stop echo.socket

Экземпляры и передача управления

Поскольку модуль echo@.service поддерживает несколько одновременных экземпляров, в его имени присутствует символ @ (вспомните, что такой символ означает параметризацию). Однако зачем может понадобиться несколько экземпляров? Причина в том, что у вас может оказаться более одного сетевого клиента, подключенного к этой службе в данный момент времени, и каждое соединение должно иметь собственный экземпляр.

В указанном случае модуль службы должен поддерживать несколько экземпляров, поскольку в файле echo.socket есть параметр Accept. Этот параметр указывает команде systemd, чтобы она не только прослушивала порт, но и принимала входящие соединения, а затем передавала входящие соединения модулю службы, создавая для каждого соединения отдельный экземпляр. Каждый экземпляр считывает данные из соединения как стандартный ввод, но при этом экземпляру не обязательно знать о том, что эти данные исходят из сетевого соединения.

примечание

Для большинства сетевых соединений требуется больше гибкости по сравнению с простым шлюзом стандартного ввода/вывода, поэтому не рассчитывайте на то, что сможете создавать сетевые службы с помощью модулей, подобных описанному здесь echo@.service.

Хотя модуль службы мог бы выполнить всю работу по принятию соединения, он не может содержать в своем имени символ @. Иначе он смог бы полностью контролировать сокет, и команда systemd не стала бы пытаться прослушивать сетевой порт, пока этот модуль службы не завершит работу.

Множество различных ресурсов и параметров передачи управления модулям служб не позволяют составить краткий обзор. К тому же документация к параметрам занимает несколько страниц руководства. Модулям, ориентированным на ресурсы, посвящены страницы systemd.socket(5), systemd.path(5) и systemd.device(5). О модулях служб есть также документ systemd.exec(5), который часто упускают из виду. Он содержит информацию о том, как модуль службы может рассчитывать на получение ресурса после активизации.

6.4.8. Совместимость команды systemd со сценариями System V

Одно свойство, которое отличает команду systemd от других init-систем нового поколения, заключается в том, что эта команда стремится выполнять более полную работу по отслеживанию служб, запущенных сценариями, которые совместимы со стандартом System V. Это работает следующим образом.

1. Сначала команда systemd активизирует модуль runlevel<N>.target, где N является уровнем запуска.

2. Для каждой символической ссылки в файле /etc/rc<N>.d команда systemd идентифицирует сценарий в каталоге /etc/init.d.

3. Команда systemd ассоциирует название сценария с модулем службы (например, для сценария /etc/init.d/foo это будет foo.service).

4. Команда systemd активизирует модуль службы и запускает сценарий с аргументом start или stop, в зависимости от его имени в файле rc<N>.d.

5. Команда systemd пытается ассоциировать любые процессы сценария с модулями служб.

Поскольку команда systemd создает ассоциацию с именем модуля службы, можно использовать команду systemctl для перезапуска службы или просмотра ее состояния. Однако не ожидайте чудес от режима совместимости со стандартом System V. Он по-прежнему должен запускать init-сценарии последовательно.

6.4.9. Команды, дополняющие systemd

Начав работу с командой systemd, вы можете заметить исключительно большое количество команд в каталоге /lib/systemd. В основном это вспомогательные программы для модулей. Например, команда udevd является частью systemd, и здесь вы обнаружите ее под именем systemd-udevd. Еще одна команда, systemd-fsck, выступает посредником между командами systemd и fsck.

Многие из этих команд существуют потому, что они содержат механизмы уведомления, которые отсутствуют в стандартных системных утилитах. Зачастую они просто запускают такие утилиты и уведомляют команду systemd о результатах. В конечном счете было бы глупо пытаться заново реализовать все команды fsck внутри systemd.

примечание

Еще одним интересным свойством этих команд является то, что они написаны на языке С, поскольку одна из целей команды systemd — уменьшить число сценариев оболочки в системе. Довольно спорный вопрос, хорошо ли это (ведь многие из этих команд могли быть написаны в качестве сценариев оболочки), но пока все работает и делает свое дело надежно, безопасно и достаточно быстро, нет смысла беспокоить спорящие стороны.

Когда вы встретите незнакомую команду в каталоге /lib/systemd, загляните в руководство. Вполне вероятно, что страница справки не только даст описание утилиты, но также сообщит и о типе модуля, который она призвана дополнять.

Если вы не пользуетесь (или не интересуетесь) вариантом Upstart, переходите к разделу 6.6, чтобы получить представление об init-процессе версии System V.

6.5. Команда Upstart

Команда init в варианте Upstart основана на заданиях и событиях. Задания — это действия в момент запуска и в процессе работы, которые выполняет команда Upstart (например, системные службы и конфигурация), а события — это сообщения, которые команда Upstart получает от себя или от других процессов (например, udevd). Работа команды Upstart состоит в запуске заданий в ответ на события.

Чтобы получить представление о том, как это работает, рассмотрим задание udev для запуска демона udevd. Его конфигурация обычно содержится в файле /etc/init/udev.conf, в котором есть следующие строки:

start on virtual-filesystems

stop on runlevel [06]

Эти строки означают, что команда Upstart запускает задание udev после возникновения события virtual-filesystems, а остановка этого задания будет выполнена после возникновения события runlevel с аргументом 0 или 6.

Существуют многочисленные варианты событий и аргументов. Например, команда Upstart может реагировать на события, возникшие как ответ на состояние задания, например на событие started udev, которое было вызвано заданием udev, упомянутым выше. Однако прежде чем детально рассмотреть задания, приведем обзор того, как работает команда Upstart на высоком уровне.

6.5.1. Процедура инициализации команды Upstart

Во время запуска команда Upstart выполняет следующее.

1. Загружает файл своей конфигурации, а также файл конфигурации заданий в каталог /etc/init.

2. Вызывает событие startup.

3. Запускает задания, которые предназначены для выполнения при появлении события startup.

4. Начальные задания приводят к возникновению новых событий, которые дают начало другим заданиям и событиям.

По завершении всех заданий, связанных с нормальным запуском, команда Upstart продолжает отслеживать события и реагировать на них во время функционирования системы в целом.

Большинство версий Upstart работает следующим образом.

1. Самым важным заданием, которое команда Upstart запускает в ответ на событие startup, является задание mountall. Это задание монтирует все необходимые для запущенной в данный момент ОС локальные и виртуальные файловые системы, чтобы могло функционировать все остальное.

2. Задание mountall порождает несколько событий, в число которых входят среди прочих filesystem, virtual-filesystems, local-filesystems, remote-filesystems и all-swaps. Данные события сообщают о том, что главные файловые системы в этой ОС смонтированы и готовы к работе.

3. В ответ на эти события команда Upstart запускает несколько важных служебных заданий. Например, задание udev запускается в ответ на событие virtual-filesystems, а задание dbus — в ответ на событие local-filesystems.

4. Среди главнейших служебных заданий команда Upstart запускает задание network-interfaces, как правило, в ответ на событие local-filesystems и готовность к работе демона udevd.

5. Задание network-interfaces порождает событие static-network-up.

6. Команда Upstart запускает задание rc-sysinit в ответ на события filesystem и static-network-up. Это задание отвечает за обслуживание текущего уровня запуска в системе, и при первом запуске без указания уровня запуска оно переводит систему на уровень запуска по умолчанию, порождая событие runlevel.

7. Команда Upstart запускает большую часть остальных заданий запуска системы в ответ на событие runlevel и новый уровень запуска.

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

Чтобы добраться до сути, приходится изрядно покопаться. Рассмотрим, например, событие static-network-up. Файл конфигурации задания network-interface.conf сообщает о том, что он порождает данное событие, но не уточняет где. Выясняется, что данное событие является результатом команды ifup, которую данное задание запускает при инициализации сетевого интерфейса в сценарии /etc/network/if-up.d/upstart.

примечание

Хотя все описанное содержится в документации (ссылка на страницу interfaces(5) с описанием каталога ifup.d идет со страницы ifup(8)), может оказаться довольно трудно выяснить, как все работает, просто читая ее. Обычно быстрее будет применить команду grep, указав название события, для нескольких файлов конфигурации, посмотреть результаты, а затем попробовать на основе фрагментов составить полную картину.

Одним из недостатков команды Upstart является отсутствие возможности простого отслеживания событий. Можно перевести ее журнал в режим отладки, в результате чего в нем будут отображены все входящие события (как правило, этот журнал хранится в файле /var/log/syslog), однако обилие посторонней информации в этом файле затрудняет определение контекста события.

6.5.2. Задания команды Upstart

Каждый файл в каталоге конфигурации /etc/init команды Upstart соответствует какому-либо заданию, а главный файл конфигурации для каждого задания снабжен расширением. conf. Например, файл /etc/init/mountall.conf определяет задание mountall.

Существуют два первичных типа заданий Upstart.

• Задачи (Task jobs). Это задания с четким окончанием. Например, задание mountall является таковым, поскольку оно завершается по окончании монтирования файловых систем.

Службы (Service jobs). У таких заданий нет определенного окончания. Серверы (демоны), такие как udevd, серверы баз данных и веб-серверы, являются заданиями-службами.

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

Просмотр заданий

Просмотреть задания команды Upstart, а также их статус можно с помощью команды initctl. Чтобы получить обзор того, что происходит в вашей системе, запустите такую команду:

$ initctl list

Результат работы будет довольно обширным, поэтому посмотрим лишь на два задания, которые могут быть найдены в типичном листинге. Вот простой пример состояния задачи:

mountall stop/waiting

Он сообщает о том, что задание mountall находится в статусе «останов/ожидание», и это означает, что оно не работает. К сожалению (на момент написания книги), вы не сможете использовать статус, чтобы определить, запущено ли уже задание или еще нет, поскольку статус «останов/ожидание» применяется также и к никогда не запускавшимся заданиям.

Службы, с которыми связаны процессы, будут отображаться в перечне статусов следующим образом:

tty1 start/running, process 1634

Эта строка говорит о том, что задание tty1 запущено и процесс с идентификатором ID 1634 выполняет его. Не все службы обладают связанными процессами.

примечание

Если вам известно имя задания job, можно просмотреть его статус напрямую с помощью команды initctl status job.

Информация о статусе в результатах вывода команды initctl (например, stop/waiting) может сбивать с толку. Левая часть (до символа /) является целью, или тем, по направлению к чему призвано работать данное задание (например, запуск или останов). Правая часть сообщает текущее состояние задания или то, что данное задание выполняет именно сейчас (например, ожидание или работа). В приведенном выше листинге задание tty1 обладает статусом start/running, это значит, что его целью является запуск. Состояние работы говорит о том, что задание запущено успешно. Для служб состояние работы является номинальным.

Случай с заданием mountall немного другой, поскольку задачи не остаются в рабочем состоянии. Статус «останов/ожидание» обычно говорит о том, что данное задание стартовало и завершило свою задачу. По завершении задачи цель меняется с запуска на останов, и теперь задание ожидает дальнейших указаний команды Upstart.

К сожалению, как отмечалось ранее, поскольку задания, которые никогда не запускались, также обладают статусом «останов/ожидание», невозможно установить, запускалось ли какое-либо задание, если вы не включили режим отладки и не заглянули в журналы, как описано в подразделе 6.5.5.

примечание

Вы не увидите те задания, которые были запущены в системе с помощью команды Upstart в режиме совместимости со стандартом System V.

Переходы между состояниями заданий

Существует множество состояний заданий, однако для переключения между ними установлен четкий порядок. Вот как, например, запускается типичное задание.

1. Все задания начинаются в статусе «останов/ожидание».

2. Когда пользователь или системное событие запускают задание, цель задания меняется с останова на запуск.

3. Команда Upstart изменяет состояние задания с ожидающего на стартующее, поэтому теперь его статус — «запуск/запуск» (start/starting).

4. Команда Upstart порождает событие starting job.

5. Задание выполняет все, что необходимо сделать для состояния запуска.

6. Команда Upstart изменяет состояние задания со стартующего на предстартовое и порождает событие pre-start job.

7. Задание выполняется своим чередом и проходит еще через несколько состояний, пока не достигает работающего состояния.

8. Команда Upstart порождает событие started.

Завершение задания содержит похожий набор изменений состояния и событий. Обратитесь к странице руководства upstart-events(7), чтобы узнать подробности обо всех состояниях и переходах для обеих целей.

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

Исследуем два файла конфигурации: один для задачи mountall, а другой — для сервиса tty1. Подобно другим файлам конфигурации, данные файлы расположены в каталоге /etc/init и называются mountall.conf и tty1.conf. Файлы конфигурации составлены из небольших фрагментов, которые называются строфами. Каждая строфа начинается с заглавного ключевого слова, например description или start.

Для начала откройте на своем компьютере файл mountall.conf. Отыщите в первой строфе нечто подобное приведенной ниже строке:

description "Mount filesystems on boot"

Эта строфа дает краткое текстовое описание задания.

Далее вы увидите несколько строф, описывающих процесс запуска задания mountall:

start on startup

stop on starting rcS

Здесь первая строка говорит команде Upstart о запуске задания при возникновении события startup (это начальное событие, порождаемое командой Upstart). Вторая строка сообщает команде Upstart о том, что задание следует остановить при возникновении события rcS, когда система перейдет в режим одиночного пользователя.

Следующие строки говорят команде Upstart о том, как себя ведет задание mountall:

expect daemon

task

Строфа task говорит команде Upstart о том, что данное задание является задачей, и поэтому в какой-то момент должно быть завершено. Строфа expect чуть сложнее. Она означает, что задание mountall породит демон, который будет действовать независимо от исходного сценария задания. Команде Upstart необходимо знать о том, когда демон прекращает работу, чтобы дать правильный сигнал о завершении задания mountall. Более подробно мы рассмотрим это в пункте «Отслеживание процессов и строфа expect команды Upstart» далее.

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

emits virtual-filesystems

emits local-filesystems

emits remote-filesystems

emits all-swaps

emits filesystem

emits mounting

emits mounted

примечание

Как отмечалось в подразделе 6.5.1, присутствующие здесь строки не сообщают о настоящих источниках событий. Чтобы их отыскать, вам придется тщательно просмотреть сценарий задания.

Вам может также встретиться строфа console, определяющая, куда должна направлять вывод команда Upstart:

console output

Если указан параметр output, команда Upstart отправляет вывод задания mountall в системную консоль.

Теперь вы увидите подробности самого задания — в данном случае это строфа script:

script

. /etc/default/rcS

[-f /forcefsck] && force_fsck=" — force-fsck"

["$FSCKFIX" = "yes"] && fsck_fix="-fsck-fix"

# set $LANG so that messages appearing in plymouth are translated

if [-r /etc/default/locale]; then

. /etc/default/locale

export LANG LANGUAGE LC_MESSAGES LC_ALL

fi

exec mountall — daemon $force_fsck $fsck_fix

end script

Это сценарий оболочки (см. главу 11), основная часть которого является подготовительной: происходит настройка языка сообщений, а также определяется необходимость использования утилиты fsck. Реальные действия происходят в команде exec mountall, в нижней части этого сценария. Эта команда монтирует файловые системы и порождает события по окончании данного задания.

Служба: tty1

Служба tty1 намного проще, она контролирует строку приглашения в виртуальной консоли. Полный файл конфигурации tty1.conf выглядит так:

start on stopped rc RUNLEVEL=[2345] and (

not-container or

container CONTAINER=lxc or

container CONTAINER=lxc-libvirt)

stop on runlevel [!2345]

respawn

exec /sbin/getty -8 38400 tty1

Самой сложной частью данного задания является момент его запуска, но пропустите пока строки, содержащие слово container, и сосредоточьтесь на следующем фрагменте:

start on stopped rc RUNLEVEL=[2345]

Эта часть сообщает команде Upstart, чтобы она активизировала данное задание после возникновения события stopped rc, когда отработает и будет завершена задача rc. Чтобы условие стало истинным, задание rc должно также установить для переменной окружения RUNLEVEL значение от 2 до 5 (см. подраздел 6.5.6).

примечание

Другие задания, которые работают с уровнями запуска, не столь требовательны. Вы можете встретить, например, такую запись: start on runlevel [2345]. Единственное существенное различие между двумя приведенными строфами start заключается в выборе момента времени; данный пример активизирует задание, как только будет установлен уровень запуска, а в предыдущем примере ожидается завершение всех процессов System V.

Здесь присутствует конфигурация контейнера, поскольку команда Upstart работает не только напрямую поверх ядра системы Linux с реальными аппаратными средствами, но способна также работать и в виртуальных средах или контейнерах. Некоторые из таких сред не располагают виртуальными консолями, и вам не придется запускать процесс getty для несуществующей консоли.

Остановка задания tty1 происходит просто:

stop on runlevel [!2345]

Строфа stop говорит команде Upstart о том, что задание следует остановить, если уровень запуска выйдет из диапазона значений от 2 до 5 (например, во время выключения системы).

Строфа exec в нижней части является командой, которую следует запустить:

exec /sbin/getty -8 38400 tty1

Эта строфа очень похожа на строфу script, которую вы видели в задании mountall, за исключением того, что для запуска задания tty1 не требуется сложная настройка — оно просто запускается одной строкой. В данном случае мы запускаем команду выдачи строки приглашения getty в устройстве /dev/tty1, которое является первой виртуальной консолью (той, в которой вы окажетесь, когда нажмете в графическом режиме сочетание клавиш Ctrl+Alt+F1).

Строфа respawn дает распоряжение команде Upstart о перезапуске задания tty1, если оно завершается. В данном случае команда Upstart запускает новый процесс getty для новой строки приглашения, когда вы выходите из виртуальной консоли.

Это были основы конфигурации команды Upstart. Подробности вы сможете найти на странице руководства init(5), а также в онлайн-источниках. Одной строфе следует уделить особое внимание. Это строфа expect, и о ней пойдет речь дальше.

Отслеживание процессов и строфа expect команды Upstart

Поскольку команда Upstart отслеживает процессы в заданиях, как только они запущены (чтобы она могла эффективно останавливать и перезапускать их), ей необходимо знать, какие процессы относятся к каждому из заданий. Эта задача может оказаться сложной, поскольку в традиционной схеме запуска системы Unix процессы ответвляются друг от друга, превращаясь в демоны, и основной процесс для какого-либо задания может начаться после одного-двух ветвлений. Без четкого отслеживания процессов команда Upstart будет неспособна завершить запуск задания или же неправильно определит идентификатор PID для задания.

Поведение задания сообщается команде Upstart с помощью строфы expect. Существует четыре основные возможности:

• отсутствие строфы expect — основной процесс задания не ветвится, следует отслеживать основной процесс;

• expect fork — процесс ветвится один раз, следует отслеживать ответвившийся процесс;

• expect daemon — процесс ветвится дважды, следует отслеживать второе ответвление;

• expect stop — основной процесс задания подаст сигнал SIGSTOP, чтобы сообщить о своей готовности. Такое бывает редко.

Для команды Upstart и для других современных вариантов команды init, таких как systemd, идеальным вариантом является первый (отсутствие строфы expect), поскольку основному процессу задания не приходится задействовать никаких собственных механизмов запуска и завершения. Другими словами, ему не приходится заботиться об ответвлении или откреплении себя от текущего терминала, с которыми разработчикам систем Unix приходится сталкиваться годами.

Во многие традиционные служебные демоны уже включены параметры стиля отладки, которые дают указание главному процессу, чтобы он не ветвился. В качестве примера можно привести демон защищенной оболочки sshd с параметром — D. Заглянув в строфы запуска в файле /etc/init/ssh.conf, можно обнаружить простую конфигурацию запуска демона sshd, которая предотвращает быстрое повторное ветвление и исключает ложный вывод в стандартную ошибку:

respawn

respawn limit 10 5

umask 022

# 'sshd — D' leaks stderr and confuses things in conjunction with 'console log'

console none

— snip—

exec /usr/sbin/sshd — D

Для заданий, которым необходимо наличие строфы expect, самым распространенным является вариант expect fork. Вот, например, пусковой фрагмент файла /etc/init/cron.conf:

expect fork

respawn

exec cron

Простой запуск задания, подобный вышеприведенному, обычно указывает на хорошо себя ведущий стабильный демон.

примечание

Стоит прочитать дополнительную информацию о строфе expect на сайте upstart.ubuntu.com, поскольку она напрямую относится к продолжительности действия процессов. Можно, например, отслеживать активность процесса и его системные вызовы, включая fork(), с помощью команды strace.

6.5.4. Управление командой Upstart

В дополнение к командам list и status, описанным в подразделе 6.5.2, можно также использовать команду initctl, чтобы управлять командой Upstart и ее заданиями. Вам потребуется прочитать страницу руководства initctl(8), но сейчас рассмотрим основы.

Чтобы запустить задание Upstart, используйте команду initctl start:

# initctl start job

Чтобы остановить задание, применяйте команду initctl stop:

# initctl stop job

Чтобы перезапустить задание:

# initctl restart job

Если вам необходимо породить событие для команды Upstart, это можно выполнить вручную с помощью такой команды:

# initctl emit event

Можно также добавить к порожденному событию переменные окружения, указав после события event параметры в виде пар key=value.

примечание

Невозможно запускать и останавливать отдельные службы, запущенные в режиме совместимости команды Upstart со стандартом System V. Из подраздела 6.6.1 вы больше узнаете о том, как это выполняется в сценариях System V init.

Существует множество способов отключить задание Upstart, чтобы оно не стартовало при загрузке системы, однако самым управляемым является следующий: определите имя файла конфигурации задания (обычно это файл /etc/init/<job>.conf), а затем создайте новый файл с именем /etc/init/<job>.override, который содержит всего одну строку:

manual

После этого единственным способом запуска указанного задания станет применение команды initctl start job.

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

6.5.5. Журналы команды Upstart

Существуют два основных типа журналов команды Upstart: журналы служб и диагностические общения, которые создает сама команда Upstart. Журналы служб записывают стандартный вывод и стандартную ошибку сценариев и демонов, которые запускают службы. Такие сообщения, хранящиеся в каталоге /var/log/upstart, являются дополнением к стандартным сообщениям, которые может выдавать служба syslog (о сообщениях syslog вы узнаете подробнее в главе 7). Сложно систематизировать записи, попадающие в эти журналы, поскольку нет стандартов. Наиболее часто встречаются сообщения о запуске и остановке, а также сообщения об аварийных ошибках. Многие службы вообще не оставляют никаких сообщений, поскольку они отправляют все в журнал syslog или в собственное средство записи событий.

Собственный диагностический журнал команды Upstart может содержать информацию о том, когда она была запущена и перезагружена, а также некоторую информацию о заданиях и событиях. Этот диагностический журнал поступает в утилиту ядра syslog. В ОС этот журнал можно, как правило, найти в файле /var/log/kern.log, а также во всеохватном файле /var/log/syslog.

В то же время команда Upstart по умолчанию заносит в журнал очень мало записей или совсем ничего, поэтому, если вы желаете увидеть что-либо в журналах, необходимо изменить приоритет журнала команды Upstart. По умолчанию имя приоритета равно message. Чтобы заносить в журнал сведения о событиях и изменениях заданий в работающей системе, поменяйте значение приоритета на info:

# initctl log-priority info

Помните о том, что это изменение не станет постоянным и будет сброшено после перезагрузки. Чтобы команда Upstart при своем запуске заносила в журнал все, добавьте в качестве параметра загрузки ключ — verbose, как описано в разделе 5.5.

6.5.6. Уровни запуска команды Upstart и совместимость со стандартом System V

К настоящему моменту мы затронули несколько областей, в которых команда Upstart поддерживает идею уровней запуска System V, а также отметили, что она обладает возможностью запуска сценариев System V в качестве заданий. Приведу более детальный обзор того, как это выглядит в Ubuntu.

1. Запускается задание rc-sysinit обычно после возникновения событий filesystem и static-network-up. До запуска этого задания уровни запуска отсутствуют.

2. Задание rc-sysinit определяет, на какой уровень запуска перейти. Как правило, это уровень запуска по умолчанию, однако задание может проверить также «старый» файл /etc/inittab или взять значения уровня запуска из параметра ядра (в файле /proc/cmdline).

3. Задание rc-sysinit запускает команду telinit, чтобы изменить уровень запуска. Эта команда порождает событие runlevel, которое задает значение уровня запуска в переменной окружения RUNLEVEL.

4. Команда Upstart получает сигнал о событии runlevel. Несколько заданий настроено на запуск при возникновении события runlevel и установке определенного уровня запуска, вследствие чего команда Upstart приводит их в действие.

5. Одно из заданий, активизированных по уровню запуска, rc, отвечает за запуск системы System V. Чтобы это выполнить, задание rc запускает сценарий /etc/init.d/rc, подобно тому как это выполнила бы команда System V init (см. раздел 6.6).

6. По завершении задания rc команда Upstart может запустить другие задания, когда будет получен сигнал о событии stopped rc (например, задание tty1, о котором шла речь в пункте «Служба: tty1» подраздела 6.5.3).

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

В любом случае есть критическая точка во время загрузки системы, когда монтируются файловые системы и производится наиболее важная часть инициализации ОС. В этот момент система готова к запуску высокоуровневых системных служб, таких как менеджеры графического дисплея и серверы баз данных. Событие runlevel удобно, как метка для этого момента. Хотя можно было бы настроить команду Upstart на использование любого события в качестве триггера. Затруднение возникает при попытке определить, какие службы запускаются в качестве заданий команды Upstart, а какие запускаются в режиме совместимости с версией System V. Простейший способ выяснить это — заглянуть в ферму ссылок уровня запуска System V (см. подраздел 6.6.2). Например, если уровень запуска равен 2, посмотрите каталог /etc/rc2.d. Все, что в нем находится, работает, вероятно, в режиме совместимости с версией System V.

примечание

Замешательство может вызвать наличие фиктивных сценариев в каталоге /etc/init.d. Для любой службы команды Upstart здесь может также находиться сценарий для такой службы в стиле System V, однако этот сценарий не делает ничего другого, кроме как сообщает вам о том, что служба была конвертирована в задание команды Upstart. Не будет также ссылки на этот сценарий в каталоге ссылок System V. Если вам встретится фиктивный сценарий, выясните имя задания Upstart, а затем используйте команду initctl для управления этим заданием.

6.6. Команда System V init

Реализация команды System V init восходит к «юности» Linux. Ее основная идея заключается в поддержке упорядоченной загрузки системы на различные уровни запуска с помощью тщательно подобранной последовательности запуска процессов. Хотя вариант System V сейчас не распространен в большинстве версий ОС для ПК, вы можете встретить команду System V init в версии Red Hat Enterprise Linux, а также во внедренных средах Linux (например, для роутеров и смартфонов).

В типичный состав команды System V init входят два главных компонента: центральный файл конфигурации и большой набор сценариев загрузки системы, дополненный фермой символических ссылок. Все начинается с конфигурационного файла /etc/inittab. Если вы работаете с вариантом System V init, отыщите строку, подобную приведенной ниже, в файле inittab:

id:5:initdefault:

Она сообщает о том, что по умолчанию устанавливается уровень запуска 5.

Все строки файла inittab построены по следующему шаблону, в котором четыре поля отделяются двоеточиями:

• уникальный идентификатор (короткая строка, как id в приведенном примере);

• применимое значение уровня запуска (или несколько значений);

• действие, которое следует выполнить команде init (в приведенном примере — установить по умолчанию значение 5 для уровня запуска);

• команда на выполнение (необязательна).

Чтобы увидеть, как работают команды в файле inittab, рассмотрим следующую строку:

l5:5:wait:/etc/rc.d/rc 5

Эта особая строка важна, поскольку она приводит в действие большую часть системной конфигурации и служб. Здесь действие wait определяет, когда и как команда System V init запускает команду: она должна запустить один раз команду /etc/rc.d/rc 5 при переходе на уровень запуска 5, а затем, прежде чем делать что-либо еще, дождаться завершения ее работы. Чтобы «сократить историю», команда rc 5 выполняет все, что находится в каталоге /etc/rc5.d и начинается с числа (в порядке следования чисел).

Ниже приводится еще несколько распространенных действий из файла inittab в дополнение к initdefault and wait.

Действие respawn

Действие respawn говорит команде init о том, чтобы она запустила следующую дальше команду и, если выполнение команды завершилось, запустила ее снова. Вам, вероятно, встретится подобная строка в файле inittab:

1:2345:respawn:/sbin/mingetty tty1

Утилиты getty обеспечивают приглашение на вход. Приведенная выше строка используется для первой виртуальной консоли (/dev/tty1), которую вы видите, когда нажимаете сочетание клавиш Alt+F1 или Ctrl+Alt+F1 (см. подраздел 3.4.4). Действие respawn заново выводит приглашение на вход, когда вы выйдете из системы.

Действие ctrlaltdel

Действие ctrlaltdel управляет тем, что выполняет система, когда вы нажимаете сочетание клавиш Ctrl+Alt+Delete в виртуальной консоли. В большинстве систем это команда перезагрузки, использующая команду shutdown (о которой рассказано в разделе 6.7).

Действие sysinit

Действие sysinit команда должна выполнить в самую первую очередь, перед переходом на какой-либо из уровней запуска.

примечание

О других доступных действиях можно узнать на странице руководства inittab(5).

6.6.1. Команда System V init: командная последовательность запуска

Теперь вы готовы узнать, как команда System V init запускает системные службы, прежде чем она позволяет вам войти в систему. Вспомните приведенную выше строку из файла inittab:

l5:5:wait:/etc/rc.d/rc 5

Эта небольшая строка приводит в действие множество других команд. На самом деле символы rc являются сокращением от run commands (запустить команды), под которыми многие подразумевают сценарии, программы и службы. Но где расположены эти команды?

Число 5 в этой строке сообщает о том, что речь идет об уровне запуска 5. Вероятно, команды будут находиться в каталоге /etc/rc.d/rc5.d или /etc/rc5.d. Уровень запуска 1 использует каталог rc1.d, уровень запуска 2 — rc2.d и т. д. Например, вы можете встретить подобные файлы в каталоге rc5.d:

S10sysklogd S20ppp S99gpm

S12kerneld S25netstd_nfs S99httpd

S15netstd_init S30netstd_misc S99rmnologin

S18netbase S45pcmcia S99sshd

S20acct S89atd

S20logoutd S89cron

Команда rc 5 запускает утилиты из каталога rc5.d, выполняя команды в такой последовательности:

S10sysklogd start

S12kerneld start

S15netstd_init start

S18netbase start

— snip—

S99sshd start

Обратите внимание на аргумент start в каждой команде. Прописная буква S в имени команды означает, что данная команда должна работать в режиме запуска, а число (от 00 до 00) определяет местоположение команды rc в последовательности команд. Команды из каталогов rc*.d обычно являются сценариями оболочки, запускающими команды из каталога /sbin или /usr/sbin.

Обычно можно выяснить, что делает конкретная команда, просмотрев ее сценарий с помощью команды less или аналогичной ей.

примечание

Некоторые каталоги rc*.d содержат команды, которые начинаются с символа K (для режима останова). В таком случае команда rc запускает команду с аргументом stop вместо аргумента start. Чаще всего команды с символом K будут встречаться вам на уровнях запуска, отвечающих за выключение системы.

Такие команды можно запускать вручную. Однако обычно это осуществляется не с помощью каталогов rc*.d, а с использованием каталога init.d, о котором речь пойдет ниже.

6.6.2. Ферма ссылок команды System V init

Содержимое каталогов rc*.d в действительности является символическими ссылками на файлы, расположенные в другом каталоге, init.d. Если вы намерены взаимодействовать со службами из каталогов rc*.d, добавлять, удалять или изменять службы, вам необходимо понимать такие символические ссылки. Полный список содержимого такого каталога, как rc5.d, обнаруживает подобную структуру:

lrwxrwxrwx. . S10sysklogd — >../init.d/sysklogd

lrwxrwxrwx. . S12kerneld — >../init.d/kerneld

lrwxrwxrwx. . S15netstd_init — >../init.d/netstd_init

lrwxrwxrwx. . S18netbase — >../init.d/netbase

— snip—

lrwxrwxrwx. . S99httpd — >../init.d/httpd

— snip—

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

Запуск и останов служб

Чтобы вручную запустить или остановить службы, используйте сценарий из каталога init.d. Например, одним из способов ручного запуска веб-сервера httpd является запуск сценария init.d/httpd start. Подобным же образом для остановки работающей службы можно применять аргумент stop (httpd stop, например).

Изменение последовательности загрузки системы

Изменение последовательности запуска системы в команде System V init обычно выполняется с помощью изменения фермы ссылок. Самое распространенное изменение — запрет работы какой-либо команды из каталога init.d на определенном уровне запуска. Следует внимательно относиться к тому, как это осуществлено. Например, вы могли бы решить удалить символическую ссылку из соответствующего каталога rc*.d. Но будьте осторожны: если вам когда-нибудь понадобится вернуть эту ссылку обратно, у вас могут возникнуть трудности при указании точного имени ссылки. Одним из лучших способов является добавление символа подчеркивания (_) в начало имени ссылки, например так:

# mv S99httpd _S99httpd

Это приводит к тому, что команда rc игнорирует файл _S99httpd, поскольку его имя не начинается с символа S или K, однако при этом исходное имя по-прежнему очевидно.

Чтобы добавить службу, создайте сценарий, подобный тем, которые находятся в каталоге init.d, а затем создайте символическую ссылку в правильном каталоге rc*.d. Проще всего это выполнить с помощью копирования и изменения одного из сценариев, который вы понимаете (в главе 11 содержится дополнительная информация о сценариях оболочки).

При добавлении службы для ее запуска выберите подходящее место в последовательности загрузки системы. Если служба будет запущена слишком рано, она может не функционировать вследствие зависимости от какой-либо другой службы. Для несущественных служб большинство системных администраторов предпочитает номера из девятого десятка. Тогда службы оказываются размещены после большинства основных системных служб.

6.6.3. Утилита run-parts

Механизм, который команда System V init использует для запуска сценариев из каталога init.d, находит себе применение в различных версиях Linux, вне зависимости от того, используют ли они команду System V init. Это утилита run-parts, единственной ее задачей является запуск подборки исполняемых команд из указанного каталога в некотором предсказуемом порядке. Можно представлять себе эту команду как исполнителя, запускающего для некоторого каталога команду ls, а затем просто выполняющего все команды, которые видит в результатах вывода.

По умолчанию запускаются все команды из каталога, однако зачастую у вас есть возможность выбрать определенные команды и игнорировать остальные. В некоторых версиях системы у вас не будет большого контроля над работающими программами. Например, Fedora поставляется с очень простым вариантом утилиты run-parts.

Другие версии, такие как Debian и Ubuntu, располагают более сложной командой run-parts. Их функции содержат возможность запуска команд на основе регулярных выражений (например, используя выражение S[0–9]{2} для запуска всех сценариев «запуск» из каталога уровня запуска /etc/init.d), а также для передачи аргументов командам. Такие возможности позволяют вам запускать и останавливать уровни запуска System V с помощью единственной команды.

Нет необходимости разбираться в деталях использования утилиты run-parts; многие даже и не знают о ее существовании. Главное — помнить о том, что она время от времени возникает в сценариях и служит только для того, чтобы запускать команды из указанного каталога.

6.6.4. Управление командой System V init

Иногда вам может понадобиться слегка «подтолкнуть» команду init, чтобы она переключила уровень запуска, заново считала свою конфигурацию или выключила систему. Для управления командой System V init используйте команду telinit. Например, для переключения на уровень запуска 3 введите:

# telinit 3

При переключении уровней запуска команда init пытается завершить все процессы, которых нет в файле inittab для нового уровня запуска, поэтому будьте бдительны при смене уровня запуска.

Когда необходимо добавить или удалить задания, а также выполнить какие-либо изменения в файле inittab, следует сообщить команде init о таком изменении и побудить ее к перезагрузке этого файла. Для этого используется следующая команда:

# telinit q

Можно также применять команду telinit s для переключения в режим одиночного пользователя (см. раздел 6.9).

6.7. Выключение системы

Команда init управляет выключением и перезапуском системы. Команды для выключения системы одни и те же, вне зависимости от используемого варианта команды init. Корректный способ выключения компьютера с Linux заключается в применении команды shutdown.

Существуют два основных способа использования команды shutdown. При останове системы она выключает компьютер и оставляет его в выключенном состоянии. Чтобы немедленно остановить компьютер, запустите следующую команду:

# shutdown — h now

На большинстве компьютеров и во многих версиях Linux при останове прекращается подача электропитания. Можно также выполнить перезагрузку компьютера. Для перезагрузки используйте флаг — r вместо — h.

Процесс выключения занимает несколько секунд. Никогда не выполняйте сброс или отключение питания на этой стадии.

В приведенном примере параметр now задает время выключения. Данный параметр является обязательным, есть много способов указать это время. Если, например, вы желаете, чтобы компьютер был выключен через определенный промежуток времени, можно использовать параметр +n, где число n задает количество минут, которое должна подождать команда shutdown, прежде чем выполнить свою работу. Другие параметры можно увидеть на странице руководства shutdown(8).

Чтобы перезагрузить систему через 10 минут, введите такую команду:

# shutdown — r +10

В Linux команда shutdown уведомляет пользователя о том, что компьютер будет выключен, но реальной работы она выполняет немного. Если вы укажете время, отличающееся от now, команда shutdown создаст файл с именем /etc/nologin. Когда такой файл присутствует, система не позволяет выполнить вход никому, кроме пользователя superuser.

Когда наступает момент выключения системы, команда shutdown дает знать команде init о начале процесса выключения. В версии systemd это означает активизацию модулей выключения; в версии Upstart — порождение событий выключения; а в версии System V init — изменение уровня запуска с 0 на 6. Вне зависимости от реализации команды init или ее конфигурации процедура обычно проходит следующим образом.

1. Команда init просит каждый процесс корректно завершиться.

2. Если какой-либо процесс не отвечает через некоторое время, команда init прерывает его, попробовав сначала сигнал TERM.

3. Если сигнал TERM не сработал, команда init использует сигнал KILL для всех затянувшихся процессов.

4. Система блокирует системные файлы на своих местах и выполняет другую подготовку к выключению.

5. Система демонтирует все файловые системы, кроме корневой.

6. Система заново монтирует корневую файловую систему в режиме «только чтение».

7. Система записывает все буферизованные данные в файловую систему с помощью команды sync.

8. На последнем шаге она дает указание ядру о перезагрузке или останове с помощью системного вызова reboot(2). Это может быть выполнено с помощью команды init или какой-либо вспомогательной команды вроде reboot, halt или poweroff.

Команды reboot и halt ведут себя по-разному, в зависимости от того, как они вызваны. По умолчанию эти команды вызывают команду shutdown с параметром — r или — h. Однако если система уже находится на уровне запуска, который соответствует останову или перезагрузке, эти команды приказывают ядру немедленно отключиться. Если вам действительно необходимо спешно выключить компьютер, несмотря на возможные повреждения в результате неорганизованного выключения, используйте параметр — f.

6.8. Начальная файловая система оперативной памяти

Несмотря на то что процесс загрузки системы Linux довольно прост, один компонент постоянно приводит в замешательство: initramfs, или начальная файловая система оперативной памяти. Представьте его в виде маленького вставного пространства пользователя, которое появляется перед запуском нормального пользовательского режима. Но сначала поговорим о том, для чего оно существует.

Проблема заключается в доступности различных типов аппаратных средств для хранения данных. Как вы помните, ядро системы Linux не взаимодействует с интерфейсами BIOS или EFI для получения данных с дисков, поэтому для монтирования корневой файловой системы ему нужны драйверы, поддерживающие механизм хранения, заложенный в основу системы. Если, например, корневая файловая система расположена на дисковом массиве RAID, подключенном к контроллеру от стороннего разработчика, то ядру в первую очередь понадобится драйвер для такого контроллера. К сожалению, существует такое множество драйверов для контроллеров устройств хранения данных, что в ядро системы невозможно включить их все, поэтому многие драйверы поставляются в качестве загружаемых модулей. Однако загружаемые модули являются файлами, и, если у ядра не будет смонтированной в первую очередь файловой системы, оно не сможет загрузить необходимые модули драйверов.

Обходной путь заключается в объединении небольшой подборки модулей драйверов для ядра, а также некоторого количества других утилит в виде архива. Загрузчик системы загружает этот архив в память перед запуском ядра. Во время запуска ядро считывает содержимое архива во временную файловую систему оперативной памяти (initramfs), монтирует ее в корневой каталог и в пользовательском режиме выполняет передачу управления команде init в файловой системе initramfs. Затем включенные в состав initramfs утилиты позволяют ядру загрузить необходимые модули драйверов для реальной корневой файловой системы. Наконец, утилиты монтируют реальную корневую файловую систему и запускают настоящую команду init.

Реализации этого процесса различны и более сложны. В некоторых версиях команда init в файловой системе initramfs — это всего лишь простой сценарий оболочки, который запускает демон udevd для загрузки драйверов, а затем монтирует реальный корневой каталог и выполняет в нем команду init. В версиях, использующих вариант systemd, как правило, можно увидеть полноценную сборку systemd, которая не использует файлы конфигурации модулей и содержит совсем немного файлов конфигурации демона udevd.

Одной из основных характеристик начальной файловой системы оперативной памяти, которая (пока) остается неизменной, является возможность обойти ее, если она вам не нужна. То есть, если ядро содержит все необходимые для монтирования корневой файловой системы драйверы, вы можете изъять начальную файловую систему оперативной памяти из конфигурации загрузчика системы. Если это удается сделать, время загрузки системы сокращается, как правило, на несколько секунд. Попробуйте выполнить это самостоятельно во время загрузки системы, использовав редактор меню загрузчика GRUB для удаления строки initrd. Лучше не экспериментировать с изменениями файла конфигурации загрузчика GRUB, поскольку можно совершить ошибку, которую будет трудно исправить. С недавних пор обойти начальную файловую систему оперативной памяти стало труднее, поскольку такие функции, как монтирование по идентификатору UUID, могут быть недоступны для обобщенных версий ядра.

Содержимое начальной файловой системы оперативной памяти легко увидеть, поскольку в большинстве современных систем это всего лишь архивы cpio (см. страницу руководства cpio(1)), сжатые с помощью утилиты gzip. Сначала отыщите файл архива, заглянув в конфигурацию загрузчика системы (используйте, например, команду grep для поиска строк initrd в файле конфигурации grub.cfg). Затем примените команду cpio, чтобы выгрузить содержимое архива в какой-либо временный каталог и исследовать результаты. Например:

$ mkdir /tmp/myinitrd

$ cd /tmp/myinitrd

$ zcat /boot/initrd.img-3.2.0-34 | cpio — i — no-absolute-filenames

— snip—

Особый интерес представляет «опорная точка» почти в самом конце процесса init для начальной файловой системы оперативной памяти. Этот участок отвечает за удаление содержимого временной файловой системы (чтобы освободить пространство) и окончательное переключение на реальную корневую файловую систему.

Как правило, вам не потребуется создавать пользовательскую начальную файловую систему оперативной памяти, поскольку это довольно кропотливая процедура. Существует множество утилит, предназначенных для создания образов такой файловой системы, и в вашей версии ОС наверняка есть какая-либо из них.

Наиболее распространенными являются утилиты dracut и mkinitramfs.

примечание

Термин начальная файловая система оперативной памяти (initramfs) относится к такой реализации, которая использует архив cpio в качестве источника для временной файловой системы. Существует устаревшая версия под названием «начальный диск оперативной памяти», или initrd, которая применяет образ диска в качестве основы для временной файловой системы. Этот вариант выходит из употребления, поскольку гораздо проще работать с архивом cpio. Тем не менее вам часто будет встречаться термин initrd применительно к начальной файловой системе оперативной памяти на основе архива cpio. Зачастую (как в приведенном примере) имена файлов и файлы конфигурации по-прежнему содержат слово initrd.

6.9. Аварийная загрузка системы и режим одиночного пользователя

Когда в системе происходит что-то неладное, первым средством помощи обычно является загрузка системы с использованием «живого» образа дистрибутива (в большинстве версий образ дистрибутива играет также вторую роль «живого» образа) или выделенного аварийного образа, такого как SystemRescueCd, который можно разместить на сменном носителе. Обычные действия по восстановлению системы заключаются в следующем:

• проверка файловых систем после сбоя;

• переустановка забытого пароля для корневого пользователя;

• устранение ошибок в важных файлах, таких как /etc/fstab и /etc/passwd;

• восстановление с помощью резервных копий после сбоя системы.

Еще одним вариантом быстрой загрузки до рабочего состояния является режим одиночного пользователя. Идея заключается в том, что система быстро загружается до корневой оболочки вместо тщательного запуска всех служб. В версии System V init режиму одиночного пользователя обычно соответствует уровень запуска 1; можно также указать этот режим загрузчику системы с помощью флага — s. Чтобы войти в режим одиночного пользователя, вам может потребоваться ввести пароль корневого пользователя.

Самой большой проблемой режима одиночного пользователя является то, что он не слишком комфортен для работы. Почти наверняка не будет доступна сеть (а если и будет, то воспользоваться ею сложно), графический интерфейс пользователя будет отключен, и даже терминал может работать некорректно. По этой причине практически всегда предпочтительнее использовать «живые» образы.