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

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

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

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

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 создайте файл модуля с именем [email protected], который позволит вам обращаться к таким модулям, как getty@tty1 и getty@tty2. Все, что следует за символом @, называется экземпляром, и при обработке файла модуля команда systemd развертывает спецификатор %I в имя экземпляра. Увидеть это в действии можно на файлах [email protected], которые входят в большинство систем, использующих команду 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

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

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

Вот файл модуля службы [email protected]:

[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

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

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

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

примечание

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

Хотя модуль службы мог бы выполнить всю работу по принятию соединения, он не может содержать в своем имени символ @. Иначе он смог бы полностью контролировать сокет, и команда 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, указав название события, для нескольких файлов конфигурации, посмотреть результаты, а затем попробовать на основе фрагментов составить полную картину.