Хотя все описанное содержится в документации (ссылка на страницу 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, а также их статус можно с помощью команды initctl. Чтобы получить обзор того, что происходит в вашей системе, запустите такую команду:
$ initctl list
Результат работы будет довольно обширным, поэтому посмотрим лишь на два задания, которые могут быть найдены в типичном листинге. Вот простой пример состояния задачи:
mountall stop/waiting
Он сообщает о том, что задание mountall находится в статусе «останов/ожидание», и это означает, что оно не работает. К сожалению (на момент написания книги), вы не сможете использовать статус, чтобы определить, запущено ли уже задание или еще нет, поскольку статус «останов/ожидание» применяется также и к никогда не запускавшимся заданиям.
Службы, с которыми связаны процессы, будут отображаться в перечне статусов следующим образом:
tty1 start/running, process 1634
Эта строка говорит о том, что задание tty1 запущено и процесс с идентификатором ID 1634 выполняет его. Не все службы обладают связанными процессами.
примечание
Если вам известно имя задания job, можно просмотреть его статус напрямую с помощью команды initctl status job.
Информация о статусе в результатах вывода команды initctl (например, stop/waiting) может сбивать с толку. Левая часть (до символа /) является
Случай с заданием mountall немного другой, поскольку задачи не остаются в рабочем состоянии. Статус «останов/ожидание» обычно говорит о том, что данное задание стартовало и завершило свою задачу. По завершении задачи цель меняется с запуска на останов, и теперь задание ожидает дальнейших указаний команды Upstart.
К сожалению, как отмечалось ранее, поскольку задания, которые никогда не запускались, также обладают статусом «останов/ожидание», невозможно установить, запускалось ли какое-либо задание, если вы не включили режим отладки и не заглянули в журналы, как описано в подразделе 6.5.5.
примечание
Вы не увидите те задания, которые были запущены в системе с помощью команды Upstart в режиме совместимости со стандартом System V.
Переходы между состояниями заданий
Существует множество состояний заданий, однако для переключения между ними установлен четкий порядок. Вот как, например, запускается типичное задание.
1. Все задания начинаются в статусе «останов/ожидание».
2. Когда пользователь или системное событие запускают задание, цель задания меняется с останова на запуск.
3. Команда Upstart изменяет состояние задания с ожидающего на стартующее, поэтому теперь его статус — «запуск/запуск» (start/starting).
4. Команда Upstart порождает событие starting