Upstart linux что это

Обновлено: 04.07.2024

Знаете, чем я сейчас занимаюсь? Пишу стартовые скрипты для systemd, и это меня бесит.

Вроде бы как мы берем операционную систему для того, чтобы экономить время на таких вещах. Вроде как пакеты должны были облегчить нам жизнь. Весьма возможно, что мой выбор операционной системы был плох, но до сегодняшнего дня жить в области Debian/Ubuntu мне было вполне комфортно.

С другой стороны, «было» — это условность. Все мы часто находимся в относительном неведении относительно того, как устроена наша операционная система. А однажды увидев код /usr/sbin/service ты уже не можешь развидеть его. Так же как и пользоваться этим инструментом.

Наверное, нужно вернуться обратно. Чтобы понять, как мы оказались в такой заднице со смесью SysV и systemd, приправленной Upstart.

TL; DR: автор ноет по поводу зоопарка из SysV, Upstart и systemd в современных дистрибутивах Debian/Ubuntu.

Казалось бы, что может быть проще? В директории /etc/init.d/ находится файл с именем службы, он отвечает за запуск и остановку. Мы делаем /etc/init.d/service stop или /etc/init.d/service start и все работает отлично.

Операционная система делает то же самое, только в зависимости от runlevel, два — так два, буду последовательно выполнять симлинки из /etc/rc2.d, которые по сути своей ведут к /etc/init.d, жизнь проста и прекрасна. Чтобы управлять последовательностью достаточно изменить сортировку файлов при помощи числа. Есть утилиты, чтобы автоматизировать создание этих симлинков.

Почему мы не могли остаться в том месте? Потому что системы изменились. Они стали, гм, сложными.

Во-первых, состояние системы ранее было практически монолитным, а сегодня может быть изменчивым. Бах — и по USB подключили сетевой адаптер. При Томпсоне такого не было! Надо реагировать, т.е. уведомить службы об этом, кого-то перезапустить, кого-то запустить, кого-то погасить.

Во-вторых, SysV было глубоко плевать на интимную жизнь программ. Он их запускал на старте, но если у тебя что-то не получалось, то это были твои личные проблемы. Отлаживать такие вещи, кстати, практически невозможно. Segmentation fault? Настоящие мужчины пишут программы, которые запускаются с первого раза и не сегфолтят, слабак.

В-третьих, структура зависимостей в SysV была достаточно простая, чего не всегда хватало.

В-четвертых, старт системы не мог быть параллельным. Запуск скриптов был строго последовательный. Это легко увидеть, если посмотреть на время старта OpenSUSE, например, лохматой 12 версии.

Правда, основная особенность SysV была не только в простоте. С простотой приходили проблемы. Например, если у меня каждый запуск скрипта start или stop отдельный, то как узнать, запущена программа или нет? Ведь ей нужно послать сигнал kill, а без PID его посылать некуда.

Свежей идеей было хранить эту цифру в файле .pid, прямо ну серьезно, свежей для своих далеких лет. Однако что делать, если программа вылетела с segmentation fault? Кратко: ничего, PID надо проверить, перед тем, как использовать.

Upstart

Мне кажется, что проблемы начались как раз тут. То есть, с того, как сообщество приняло Upstart. Это и задало дальнейший тон. Но по порядку.

Upstart поддерживал события. Он мог следить и перезапускать программы. Он умел выстраивать зависимости. Ну и с параллельностью у него тоже было все в порядке.

Кроме одной, огромной бочки дегтя, о которой я скажу дальше, я не помню никаких толком претензий к Upstart. А вот бочкой было то, что разработчики софта его в целом проигнорировали.

Почему? Я не знаю. Скорее всего потому, что совместимость с SysV была приоритетом для Upstart. Поэтому разработчикам ничего не нужно было менять.

В итоге, несмотря на то, что Upstart царствовал в Ubuntu 5 лет на протяжении с 2009 до 2014 года, огромное количество софта так и не перешло на него!

С одной стороны, я не могу винить в этом только разработчиков. Они, в конце концов, пишут программы. Как лучше запускать эти программы в системе — не их дело. Однако скрипты для SysV они пишут. Хотите примеров? Посмотрите, на что похож скрипт запуска postfix в Debian. Этот код монструозен, он ужасен, это же просто страшно.

Однако еще страшнее то, что многие администраторы вообще не видят и не понимают разницы. Они пишут:

И свято верят, что apache2 должен стартовать. Аргх, он не должен. Понимаете? Не должен. Запустится утилита /usr/bin/service, которая примется со страшной силой угадывать, как же нужно стартовать эту службу, а потом передаст вашу просьбу SysV или Upstart. Если сможет правильно угадать, ага.

service вообще не часть пакета Upstart. Оно вообще не оттуда, но как-то уживается в этом веселом кругу. Чтобы увеличить количество ада, некоторые разработчики делают скрипты /etc/init.d ссылающимися на Upstart. Эдакий уроборос, чтобы если вдруг администратор из лесу вышел и в Ubuntu 16.04 LTS напишет

Чтобы все работало.

Отдельно следует сказать про PID. Upstart не нужен PID в файле. Почему? Потому что любой запущенный им процесс остается его дочерним. Если вдруг он вылетит, то Upstart об этом узнает. И поскольку команды запуска и остановки тоже проходят через него, то тут нет никакой проблемы.

Однако как быть с сервисами, которым нужен fork? Ну для начала их надо спросить, зачем им это? Ведь в целом, fork применялся в основном для того, чтобы детачнуться от стартовавшего их процесса, но в случае с Upstart это делать незачем. Если у нас умер init, то у нас есть чуть больше проблем, чем неработающий postfix.

Да что уж там, сейчас, когда 16.04 LTS уже здесь, как думаете, при помощи чего стартует Apache2? postfix? Еще куча всякого? SysV.

Правда, в 16.04 им помогает systemd.

systemd

В целом, мне нравится systemd, честно. Его логика мне гораздо приятнее той, что была у Upstart. Правда, если бы еще Debian взяла бы не 215 релиз, а 218, то жить было бы еще лучше, но черт с ним, мы переживем и без команды edit, если надо.

И systemd можно долго ругать, но это уже стандарт. Однако как вы думаете, что делают разработчики с systemd? В основном игнорируют.

Итак, что привнес systemd? Генераторы! Тысячи их!

Кратко, если Upstart не выпендривался, а просто повторял поведение SysV, то systemd до такого не опускается. Он берет существующий /etc/init.d/service и на основе него генерирует скрипт для systemd. Его потом и запускает.

Ну вот как бы да, вот примерно вот так оно и получается. Я не буду рассказывать о том, что это далеко не всегда работает так, как надо. Вернее, стартовать оно стартует. Не вздумайте в каком-нибудь продакшене положиться на рестарт такого сервиса, мониторинг станет вашим лучшим будильником.

И да, вы же понимаете, что systemd тем более не нужен PID, но увы. В сообществе это до сих пор остается толком не понятым.

К разработчикам

Да, ребята, я согласен, еще раз, запуск программы не есть ваша забота. Однако кто, как не вы, лучше знает, как спроектировать беспроблемный старт? Ведь одно дело, если команда старта выглядит так:

А совсем другое, если так:

Давайте перестанем уже размазывать настройки между /etc/config.conf и /etc/default/service?

Давайте перестанем пытаться управлять стартом службы при помощи параметра START=yes в /etc/default/service? Нет, я понимаю, что «xyes» смотрится отличной шуткой, но надоело уже!

Давайте уже решим, что systemd — он везде. И что под него можно смело адаптироваться.

Инициализация – это очень важная процедура, лежащая в основе любой операционной системы на основе Unix. Она управляет сервисами и сценариями. Особенно инициализация важна для серверов, которые нуждаются в оптимизации производительности.

Инициализация состоит из следующих этапов:

Загрузка сервера;
Запуск процесса init (как правило, он имеет PID 1);
Запуск последовательности предопределённых задач;

Инициализация обеспечивает корректный запуск и отключение сервера.

В данном руководстве речь пойдёт об Upstart – удобной и производительной системе инициализации.

Краткий обзор Upstart

Система Upstart изначально разрабатывалась с упором на гибкость, потому предлагает множество подходов, которых нет в стандартных системах инициализации. По умолчанию её использую т системы Red Hat Enterprise Linux (RHEL) 6, Chrome OS и дистрибутивы Ubuntu до версии 15.04.

Процессы

Upstart делит рабочие процессы (jobs) на задачи (task jobs) и сервисы (service jobs, могут работать в фоновом режиме). Также существуют процессы, которые работают до тех пор, пока их не остановит пользователь.

События

События – это сигналы, или вызовы, инициирующие определённое действие. Наиболее общим примером события является мониторинг процесса (starting, started, stopping, stopped).

Реализация событий

Процесс запуска события называется реализацией. Как правило, события запускаются процессами, но в случае необходимости администратор может запустить их вручную с помощью команды:

initctl emit <event>

Ещё одна полезная команда для работы с Upstart: init control.

Конфигурации процесса

Примечание: Система Upstart очень производительна в Ubuntu, потому в данном руководстве используется сервер Ubuntu 14.04.

Чтобы настройки процесса были валидными, конфигурационный файл должен соответствовать таким требованиям:

Он не должен быть пустым;
Не должен содержать ошибок;
Должен содержать хотя бы один блок команд (stanza).

Теперь попробуйте создать файл testjob.conf в каталоге /etc/init. Расширение файла .conf указывает на файл конфигураций процесса.

sudo nano /etc/init/testjob.conf

Существует два блока, с помощью которых можно определить цель и автора процесса: description и author. С них должен начинаться файл:

description "A test job file for experimenting with Upstart"
author "Your Name"

Этот процесс должен загружаться после того, как загрузятся все остальные сервисы и процессы. Для этого добавьте строку:

start on runlevel [2345]

Уровень выполнения, или runlevel – это режим работы операционной системы компьютера. Уровни выполнения обозначаются цифрами от 0 до 6.

Теперь нужно добавить исполняемый код. Строка начинается с exec, чтобы обозначить, что данный код должен быть обработан оболочкой Bash.

exec echo Test Job ran at `date` >> /var/log/testjob.log

Обратите внимание: команда echo использует обратные кавычки, чтобы запустить команду date, а затем записывает результат команды в лог. Если вы пропустите обратные кавычки, на экране просто отобразится слово date.

Сохраните и закройте файл.

Чтобы убедиться, что всё работает корректно, запустите процесс вручную. Но сначала нужно проверить синтаксис на ошибки:

Если команда обнаружила ошибки, исправьте их. Если ошибок нет, команда вернёт:

File /etc/init/testjob.conf: syntax ok

При помощи следующей команды можно управлять процессами и фоновыми сервисами (например веб-сервером). Её базовый синтаксис:

sudo service <servicename> <control>

В поле control можно использовать такие команды:

restart: перезапуск
start: запуск
stop: остановка сервиса
status: состояние сервиса

Чтобы вручную запустить процесс, используйте команду:

sudo service testjob start

Теперь проверьте файл testjob.log:

Эта команда прочитает заданный файл и выведет его содержимое:

Test Job ran at Fri Aug 1 08:43:05 BST 2014

Это значит, что тестовый процесс работает правильно.

Перезапустите сервер, войдите и снова запустите команду:

В файле должна появиться ещё одна строка:

Test Job ran at Fri Aug 1 08:44:23 BST 2014

Так на примере одного процесса вы научились основам Upstart. Теперь пора ознакомиться с событиями и состояниями процессов.

Состояние процессов и события

Рабочие процессы пользователей запускаются в их сессиях. Такие процессы не являются общесистемными.

Все процессы независимо от их вида всегда определяются в конфигурационном файле (.conf), где их имя должно представлять сервис или выполняемую задачу.

Каждая такая задача имеет целью запуск (start) или остановку (stop). Между этими двумя целями находится ряд состояний задачи, который определяет текущее действие процесса в зависимости от цели.

waiting: исходное состояние процесса.
starting: подготовка к запуску.
pre-start: загрузка предпусковых задач.
spawned: запуск разделов сценария.
post-start: выполнение операций после запуска процесса.
running: процесс полностью запущен.
pre-stop: подготовка к остановке процесса.
stopping: остановка процесса.
killed: процесс остановлен.
post-stop: чистка окружения после остановки процесса.

Процесс в состоянии post-start считается запущенным процессом. Он остаётся запущенным до состояния pre-stop, в котором он готовится к остановке. После этого процесс останавливается и переходит в состояние post-stop (очистка системы).

Чтобы увидеть, как процесс изменяет свои состояния, переведите приоритет лога Upstart (/var/log/upstart/) в debug:

sudo initctl log-priority debug

Обратите внимание: состояния и события – не одно и то же.

Процессы сервисов

Процесс сервиса использует конфигурационные файлы, которые позволяют запускать процессы в фоновом режиме.

Для примера попробуйте установить сервер Node.js.

Примечание: Node.js – это кроссплатформенная среда для серверных и сетевых приложений.

Node.js – очень лёгкий пакет, но по умолчанию он не установлен в Ubuntu 14.04. Чтобы установить его, введите:

sudo apt-get install nodejs

Теперь попробуйте создать сервис. Для этого создайте новый файл nodetest.conf в каталоге /etc/init.

sudo nano /etc/init/nodetest.conf

Примечание: Имя файла должно быть описательным.

Добавьте в файл описание и автора процесса:

description "Service for a test node.js server"
author "Your Name"

Чтобы настроить автоматический запуск и отключение этого приложения на основе Node, добавьте в файл такие строки:

start on filesystem or runlevel [2345] stop on shutdown

Уровень запуска в сочетании с событием filesystem обеспечивает запуск процесса во время загрузки сервера.

Теперь нужно добавить в файл определённые ранее блоки. Поскольку это приложение является серверным, нужно добавить в конфигурации логирование. Чтобы регистрировать запуск и остановку приложения, используйте действия script, pre-start script и pre-stop script.

Как видите, pre-start и pre-stop – это состояния процессов, но их можно добавлять в блоки.

Сначала нужно добавить сам сценарий процесса. Он получит ID процесса для фонового сервера Node, а затем запустит сценарий приложения. Обратите внимание на отступы в блоке – они важны для корректного синтаксиса.

export HOME="/srv"
echo $$ > /var/run/nodetest.pid
exec /usr/bin/nodejs /srv/nodetest.js

Приложению Node необходима переменная домашнего каталога, потому /srv экспортируется в первой строке блока. Символы $$ устанавливают PID процесса и создают файл для него.

echo "[`date`] Node Test Starting" >> /var/log/nodetest.log

Обратите внимание: блок pre-stop содержит строку, которая удаляет PID-файл. Эта задача будет частью процесса остановки.

rm /var/run/nodetest.pid
echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log

В результате файл будет иметь такой вид:

description "Test node.js server"
author "Your Name"
start on filesystem or runlevel [2345] stop on shutdown
script

export HOME="/srv"
echo $$ > /var/run/nodetest.pid
exec /usr/bin/nodejs /srv/nodetest.js

end script
pre-start script

echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script

rm /var/run/nodetest.pid
echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log

Сохраните и закройте файл.

Как сказано в строке exec, сценарий Node.js будет запущен с сервера, потому нужно создать файл nodetest.js:

sudo nano /srv/nodetest.js

Полученный сценарий выполняет следующие действия:

При помощи следующего кода можно запустить приложение Node:

var http = require("http");
http.createServer(function(request, response) response.writeHead(200, );
response.write("Hello World");
response.end();
>).listen(8888);

Сохранив файл, убедитесь, что в синтаксисе нет ошибок.

init-checkconf /etc/init/nodetest.conf
File nodetest.conf: syntax ok

Убедившись, что код не содержит ошибок, перезапустите сервер и откройте ссылку:

На экране появится фраза Hello World.

Теперь нужно проверить, работает ли логирование. Откройте указанный в настройках лог и найдите в нём метки времени в строке Starting. После остановки сервиса в логе появится строка Stopping.

cat /var/log/nodetest.log
[Sun Aug 17 08:08:34 EDT 2014] Node Test Starting
[Sun Aug 17 08:13:03 EDT 2014] Node Test Stopping

Для запуска стандартных команд (start, stop, restart и т.д.) используется следующий синтаксис:

sudo service nodetest restart

Заключение

Данное руководство охватывает только основы работы с Upstart. Открытая система Upstart – производительное и надёжное средство для написания процессов.

Идея написания данной статьи возникла практически одновременно с моим удивленным взглядом на экран монитора и неуверенным бормотанием: «А где же /etc/inittab?». Не помню уж точно зачем, мне понадобилось выяснить, на каком уровне грузится моя Ubuntu 7.10 — the Gutsy Gibbon. Не найдя традиционного /etc/inittab я некоторое время находился в ступоре. Уже потом, поковыряв google, нашел ответ на мой, как оказалось, простой вопрос.

Традиционный init

Вообще, если попытаться описать процесс загрузки Linux в двух словах, то это будет звучать примерно так. После включения компьютера, загрузки ядра в память, монтирования корневой файловой системы, опроса и инициализации оборудования передача управления по дальнейшей загрузке ОС передается специальному демону, называемому init. Задача init — это запуск всех остальных процессов, нужных для корректного функционирования ОС. В принципе, при помощи параметра ядра init можно указать ядру запускать все, что нам заблагорассудится (что в некоторых специфических дистрибутивах Linux и сделано), однако практически во всех традиционных дистрибутивах запускается именно демон init. Идея на самом деле очень простая и классная. Зачем ядру заморачиваться над запуском хреновой тучи приложений, если достаточно позаботиться лишь о запуске одного процесса, который и будет разруливать дальнейшую загрузку/работу/остановку системы.

Традиционный демон init определяет 7 так называемых «уровней выполнения». Для каждого такого уровня должен быть определен вполне определенный набор системных служб, запускаемых во время загрузки, получающих команды во время работы и останавливаемых во время перезагрузки системы или выключения питания:

0 — система полностью прекратила работу
1 или S — однопользовательский режим
2. 5 — многопользовательские режимы
6 — перезагрузка системы

Следует отметить, что перечисленный выше список — это всего лишь традиция. То есть, никто не мешает вам для каждого уровня определить свой набор служб и пользоваться в свое удовольствие.

После запуска, демон init читает конфигурацию из файла /etc/inittab и на основании этой конфигурации начинает уже, так сказать, непосредственную деятельность. Грубо говоря, в файле /etc/inittab содержатся указания о том, что должен делать демон init на каждом из уровней.

В какой-то момент формат файла /etc/inittab оказался слишком устаревшим и перестал обеспечивать требуемую разработчиками функциональность, после чего в Linux появился каталог /etc/init.d, содержащий в себе файл /etc/init.d/rc

shell-сценарии запускающие все необходимое, а файл /etc/initttab стал выполнять функцию хранилища номера уровня по-умолчанию и вызова файла /etc/init.d/rc при смене уровней работы системы.

В каталоге /etc/init.d находятся сценарии запуска/перезапуска/останова системных служб. Все эти сценарии могут вызываться с разнообразными параметрами, обязательными из которых являются параметры start и stop. Нужно вам, например, запустить сервер sshd — вы просто даете команду /etc/init.d/sshd start и shell-сценарий делает все необходимо для запуска сервиса. Нужно остановить? Пожалуйста: /etc/init.d/sshd stop. Сам демон init работает не напрямую со сценариями, а следующим образом.

Существует несколько каталогов /etc/rcX.d, где X — это номер уровня работы системы. В каждом из этих каталогов находятся символьные ссылки на сценарии из каталога /etc/init.d. Довольно удобно, поскольку если нужно будет внести изменения в скрипт, то только в одном месте.

Каждая ссылка в каталоге /etc/rcX.d имеет вид YNNname, где Y — определяет параметр, передаваемый скрипту, NN — двузначный номер, name — имя файла сценария работы со службой из каталога /etc/init.d. Y должна быть одной из букв S или K, соответственно определяя, start или stop передавать скрипту. NN — задает очередность выполнения скриптов. Таким образом, при переходе на другой уровень работы системы, init сперва выполняет все K-сценарии в соответствующем текущему уровню каталоге /etc/rcX.d и потом выполняет все S-сценарии в соответствующем уровню, на который переходит система, каталоге /etc/rcX.d.

Для переключения между различными уровнями работы системы существует утилита telinit, которая умеет сообщать демону init, на какой уровень нужно перейти.

Таким вот, в принципе, несложным образом и живет ОС Linux от запуска до остановки. Заранее прошу прощения за мой местами кривой стиль изложения материала. Всех заинтересовавшихся более подробно темой работы демона init отправляю к man-страницам init (8), inittab (5), telinit (8), runlevel (8).

Что такое Upstart и чем он лучше

Начиная с Ubuntu 6.10 старый добрый init был заменен более функционально-продвинутым аналогом, которое авторы назвали Upstart. Основной козырь Upstart в том, что его работа основана на событиях. Это означает, что, в отличие от init, Upstart запускает и останавливает задачи не просто вызывая соответствующие shell-скрипты, а еще и наблюдает за работой запущенных им задач, основываясь на событиях, получаемых им от приложений. Это дает возможность, например, перезапустить в случае чего внезапно упавшую службу самим демоном Upstart, а не возлагать это на какие-то потусторонние программы.

Прежде чем продолжать дальше, хочется отметить, что в терминологии Upstart существует два понятия: служба (service) и задача (task). Главное отлицие службы от задачи состоит в том, что служба перезапускается в случае внезапного ее завершения, а задача — нет. Краткий перечень основных возможностей Upstart, взятый на сайте проекта:

задачи и службы запускаются и останавливаются при помощи событий
в момент запуска/остановки службы или задачи генерируется событие
события могут быть получены от любого процесса в системе
при падениях службы могут автоматически перезапускаться
двунаправленный обмен данными с демоном init с целю опроса состояний запущенных служб, выяснения причин их останова и тому подобное.

Из функционала, который только планируется в будущих версиях Upstart на сайте отметили следующие моменты:

генерация событий через определенный интервал времени или с использованием планировщика
генерация событий в ответ на изменение содержимого файлов/каталогов
наблюдение и перезапуск демонов процессы которых отделены от родительских
возможность непривилегированным пользователям создавать свои собственные службы и управлять ими
связь с демоном init средствами DBUS

Установка UpStart

Первым делом, проверяем, соответствует ли наша система требованиям:

Linux >= 2.6.17
GCC >= 4.1
glibc >= 2.4

Конфигурируем исходный код для компиляции:

О дополнительных возможных параметрах конфигурирования можно узнать из файла INSTALL, находящегося непосредственно в корне дерева исходных кодов.

Описание заданий

После успешной установки Upstart, необходимо создать определения заданий для того, чтобы система смогла загрузиться. Другими словами, задания как раз есть, что чем оперирует Upstart в своей работе. Чтобы быстрей понять, как это все делается и, так сказать, увидеть своими глазами, можно скачать архив примеров заданий. Возможно, вам придется их немного видоизменить для корректной работы с вашей системой, однако все необходимое для начальной конфигурации системы и успешного первого запуска в архиве примеров есть. Все примеры необходимо распаковать в каталог /etc/event.d. Именно из него Upstart берет все необходимое для работы (про /etc/inittab все дружно забыли). За исключением моментов описанных в разделе «Upstart on Other Distributions» все скрипты в каталогах /etc/rcX.d можно оставить без изменений. все должно заработать.

Последний штрих и перезагрузка

Когда все готово, можно попробовать перегрузить Linux и посмотреть, что у вас получилось. Перед перезагрузкой не забудьте проверить значение параметра init, передаваемого ядру вашим загрузчиком, в случае, если Upstart установил исполняемый файл init в отличный от /sbin каталог. Вообще, в принципе, настоятельно рекомендуется для начала не заменять стандартный sysvinit на init Upstart, а установить его в какой-то другой каталог и при помощи параметра ядра init сперва все тщательно протестировать.

Пишем задания

Тем, кому необходимо расширить стандартный набор заданий или просто интересно знать, как все это сочиняется и работает.

Сразу обращу ваше внимание на то, что на сегодняшний день формат файла задания в Upstart считается еще сырым и может в будущем претерпевать изменения, о чем и сообщается на сайте. Так что, будьте готовы, в случае чего, погрузиться в чтение документации к новым версиям и приведению в соответствие написанных вами ранее заданий.

Все задания помещаются в файлы, расположенные в каталоге /etc/event.d. Имена файлов должны соответствовать именам заданий и сами файлы не должны быть исполняемыми.

Один или более пробелов в тексте файла будут обрабатываться как один пробел, если только эти пробелы не заключены в одинарные или двойные кавычки. Переводы строки разрешены только в пределах кавычек или если перед переводом строки поставить обратный слеш. Также, подобно bash-скриптам, разрешены комментарии, начинающиеся с символа решетки.

exec и script

Каждое задание обязано иметь запись script или exec. Эта запись определяет способ запуска задания. exec используется в случае, когда вы запускаете какую-то программу с вашей файловой системы с возможностью передачи дополнительных параметров вызываемой программе.

Запись script используется для вставки bash-кода непосредственно в файл задания. Все, что вы здесь укажете, будет выполнено стандартным интерпретатором /bin/sh с параметром -e, таким образом позволяя прервать скрипт в случае неправильного использования любой команды. Запись script должна заканчиваться строкой «end script».

pre-start script и post-stop script

В дополнение к стандартным записям exec и script существует возможность создавать записи pre-start и post-stop. Данную возможность удобно использовать в случае необходимости каких-либо подготовительных действий перед запуком самого скрипта или исполняемого файла, а также при необходимости выполнять какие-то действия по их завершению. Очень важно понимать, что Upstart подразумевает, что выполняемый в этой записи скрипт или бинарный файл обязательно завершат свою работу, а не буду болтаться запущенными. Обязательно учитывайте это при написании заданий!

start on и stop on

Данная запись позволяет вам указать, при возникновении каких именно событий должно выполняться или останавливаться ваше задание.

Самое первое событие, которое генерирует Upstart — это событие startup. Данное событие происходит в тот момент, когда корневая файловая система еще не доступна для записи и отсутствует поддержка сети.

В случае с заданиями из архива с примерами, имеется также событие runlevel X, где X может быть числом от 1 до 6 или символом S. При генерации таких событий будут выполняться init-скрипты, соответствующие уровню запуска X.

И, наконец, вы можете управлять своими заданиями на основе событий, возникающих, в процессе запуска/останова других заданий. Для этого вы можете использовать события stopped и started.

Для определения событий, по которым ваше задание должно запускаться используйте запись start on, останавливаться — stop on. Все просто!

console

Эта запись используется для указания заданию, откуда оно должно брать ввод и вывод для работы. Значение параметра console может быть: output (в этом случае используется устройство /dev/console), owner (тоже самое, только с возоможностью послать процессу Ctrl+C) и none (это значение является значением по-умолчанию, иползуется устройство /dev/null).

Управление заданием

start и stop

Задания можно запускать и останавливать при помощи программ start и stop, размещенных в каталоге /sbin. Каждой из них необходимо передать в качестве параметров список заданий для обработки. Результаты своей работы обе программы предоставляют в поток стандартного вывода.

status

Программа status позволяет, как видно из названия, узнать состояние, в котором находится задание.

Сначала выводится название задания, затем последняя операция, которая выполнялась над заданием (запуск/останов), текущее состояние и идентификатор процесса, если таковой имеется.

initctl list

Список всех заданий и их состояний на текущий момент можно получить при помощи команды initctl list.

initctl emit

При помощи это команды у вас есть возможность генерировать любое событие. Очень удобная штука при написании собственных заданий. Например, имеется задание:

Следующая команда заставит его выполниться

Заключение

Вот так, в двух словах, получилась, я надеюсь, статья об Upstart, состоящая процентов на 80 из вольного перевода страницы «Getting Started» с официального сайта Upstart. Have Fun! :-)

В операционной системе Linux и других системах семейства Unix после завершения загрузки ядра начинается инициализация Linux системы, сервисов и других компонентов. За это отвечает процесс инициализации, он запускается ядром сразу после завершения загрузки, имеет PID 1, и будет выполняться пока будет работать система.

Процесс инициализации запускает все другие процессы, которые должны быть запущены, это родительский процесс для всего, что выполняется в системе. Другие процессы могут тоже создавать дочерние процессы, но если родительский процесс завершается, для его дочерних процессов родительским становится процесс инициализации.

Системы инициализации Linux

За время развития операционных систем были созданы различные системы инициализации Linux. В разных дистрибутивах использовались разные системы. В этой статье мы рассмотрим лучшие системы инициализации, которые вы можете сейчас использовать. Мы начнем с более старых систем с меньшим функционалом, чтобы понять с чего все начиналось, затем подойдем к более новым, созданным в последнее время.

1. System V Init

System V или SysV - это довольно старая, но до сих пор ещё популярная система инициализации Linux и Unix подобных операционных систем. Она была основой для создания многих других систем инициализации, а также первой коммерческой системой инициализации разработанной для Unix в AT&T. Она была разработана еще в 1983 году.

Почти все дистрибутивы Linux изначально использовали SysV. Исключением была только Gentoo, в которой использовалась собственная система инициализации и Slackware, с инициализацией в стиле BSD.

Основные возможности SysV:

Написание файлов запуска служб на bash;
Последовательный запуск служб;
Сортировка порядка запуска с помощью номеров в именах файлов;
Команды для запуска, остановки и проверки состояния служб.

Никакой параллельной загрузки, системы зависимостей, запуска по требованию и автоматического запуска здесь не было и в помине.

С момента ее разработки прошло много лет и из-за некоторых недостатков были разработаны другие системы для ее замены, они хоть и имели новые функции и были более эффективны, но они были по-прежнему совместимы с SysV.

2. OpenRC

OpenRC - это система инициализации Linux и Unix подобных операционных систем совместимая с Sys V Init и поддерживающая систему зависимостей во время запуска. Она приносит некоторые улучшения в SysV, и как и другие системы инициализации Linux, совместима с ней, но вы должны иметь в виду, что OpenRC не заменяет полностью файл /sbin/init. Эта система инициализации используется в Gentoo и дистрибутивах BSD.

Кроме стандартных возможностей SysV, здесь поддерживается также:

Поддержка зависимостей служб;
Поддержка параллельного запуска служб;
Поддерживает настройку в одном отдельном файле;
Работает как демон;

По сравнению с SysV тут появилось много новых возможностей, но все еще не все те, что нужны для оптимальной работы системы.

3. Systemd

Systemd - это новая система инициализации Linux. Она была введена по умолчанию в Fedora 15, а сейчас используется почти во всех популярных Linux дистрибутивах. Это не только инициализирующий процесс, поддерживающий огромное количество возможностей, но и набор инструментов для управления службами и этими возможностями из системы. Основная цель - иметь полный контроль над всеми процессами во время их запуска и на протяжении всего выполнения.

Systemd очень сильно отличается от всех существующих систем инициализации, тем как она работает с сервисами, и даже конфигурационными файлами сервисов. Совместимости со скриптами SysV нет, их нужно преобразовать в linux systemd unit файлы.

Вот ее основные особенности:

Понятный, простой и эффективный дизайн;
Параллельная загрузка служб на основе зависимостей;
Поддерживается завершение дополнительных процессов;
Поддерживается собственный журнал с помощью journald;
Поддерживается планирование заданий с помощью таймеров Systemd;
Поддерживается управление сетью с помощью networkd;
Для управления DNS используется systemd-resolved;
Хранение журналов в бинарных файлах;
Сохранение состояния сервисов linux systemd для возможного восстановления;
Улучшенная интеграция с Gnome;
Запуск сервисов по требованию;

4. Runinit

Runinit - это кроссплатформенная система инициализации, которая может работать в GNU Linux, Solaris, BSD и MacOS. Это отличная альтернатива для SysV с поддержкой мониторинга состояния служб.

Здесь есть некоторые интересные особенности, которых нет в других системах инициализации:

Полный контроль сервисов, каждый сервис привязывается к своему каталогу;
Надежное средство журналирования и ротации логов;
Быстрая система загрузки и выключения;
Портативность;
Легкое создание файлов конфигурации служб;
Небольшое количество кода системы инициализации.

5. Upstart

Upstart - это система инициализации на основе событий, разработанная в Canonical и призванная заменять SysV. Она может запускать системные службы, выполнять над ними различные задачи, инспектировать их во время выполнения, а также выполнять нужные действия в ответ на события в системе.

Это гибридная система инициализации, она использует как SysV скрипты запуска, так и файлы служб Systemd. Вот ее самые заметные особенности:

Изначально разработанная для Ubuntu, но может использоваться и в других дистрибутивах;
Запуск и остановка служб на основе событий;
Генерация событий во время запуска и остановки служб;
События могут быть отправлены обычными процессами;
Связь с процессом инициализации через DBus;
Пользователи могут запускать и останавливать свои процессы;
Перезапуск служб, которые неожиданно завершились;
Параллельная загрузка сервисов;
Автоматический перезапуск служб;

Большинство ее возможностей работают благодаря интеграции с системой инициализации Systemd. В последнее время всё меньше используются скрипты SysV init и всё больше применяются юнит файлы Systemd. Рано или поздно Systemd вытеснит и полностью заменит Upstart в Ubuntu.

Выводы

Как я уже говорил, система инициализации запускает и управляет всеми другими процессами в системе Linux. SysV до недавнего времени была основной системой инициализации в большинстве дистрибутивов Linux, но из-за некоторых своих недостатков для нее было разработано несколько замен, в том числе Systemd.

Какие системы инициализации Linux используются в вашем дистрибутиве? В списке обозначены не все существующие системы, какую из них нужно добавить в список? Напишите в комментариях!

Читайте также: