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

примечание

Хотя все описанное содержится в документации (ссылка на страницу 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