Внутреннее устройство Linux
Шрифт:
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, поскольку
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 может содержать информацию о том, когда она была запущена и перезагружена, а
В то же время команда 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.