Внутреннее устройство Linux - Уорд Брайан - Страница 45

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: