Управление сервисами в upstart

1. Не знаю, как именно в Трасти, но системы с upstart долго были «промежуточными», в них оставались скрипты в /etc/init.d, далеко не всё запускалось с помощью upstart. Так что изучайте и /etc/init и /etc/rcX.d (ссылки на /etc/init.d). А относительно того, что лишнее, решайте сами.

2. Насколько знаю, нет. Сервисы активируются по событию, они не знают в результате чего это событие возникает.

3. Найти getty (mingetty) в списке процессо и прочитать man по нему. Хотя очистка экрана может быть не только от getty, но, например, в .bash_logout.

.bash_logout исключён, экран очищается перед вводом приглашения login:
В /etc/init/tty1.conf прописан agetty. Добавил опцию --noclear - всё равно очищается.
И как узнать какой рунлевел?

И как узнать какой рунлевел?

runlevel разве нет?

Опция точно принята upstart'ом, в смысле в списке процессов, если не логинится в первой консолии, на tty1 будет ″agetty″ c опцией ″--noclear″?

Ещё может быть управляющая последовательность в /etc/issue.

Я уже разобрался, опция --noclear работает, но экран очищает какой-то сервис, запускаемый перед getty. Как узнать в каком порядке сервисы запускаются?

Можно указать в командной строке ядра (через загрузчик ядра) опцию ″--verbose″, тогда будут всякие сообщения от upstart, правда до запуска логгера они будут идти на консоль. Ещё можно во всех службах добавить строку ″console log″, тогда будут создаватся файлы в /var/log/upstart/ для каждого сервиса и по времени создания файла (на ext4 через debugfs) можно узнать когда запускался сервис.

Сложно. Задача по-быстрому разобраться с upstart не решилась.

runlevel есть, /etc/inittab нет

Понятно, что промежуточная система. Я в Trusty Tahr нашел признаки наличия и init, и upstart, и systemd. Такой ещё вопрос, то что демоны выводят на stdout, stderr перенаправляется в журнал как это в systemd-based дистрибутивах происходит?

Те демоны, которые стартуют через скрипты в /etc/init.d живут своей жизнью, их stdout/stderr идёт на консоль.

Те, которые службы upstart (/etc/init), начиная с версии upstart 1.4 идут в отдельные log-файлы (/var/log/upstart/*.log). Но это может быть переопределено как файле юнита, директива ″console none|output|log″, так и глобально, в параметрах ядра (″--no-log″, ″--default-console″).

Ну да, а вызов демонов стартующих через скрипты всё равно идёт через юнит rc.conf
Upstart может запускать сервисы в «режиме трассировки»?

Насколько я знаю, трассировки нет. Всё что есть я пречислил выше (--verbose и console log).

Да, кстати, при всём уважении я так и не разобрался как управлять сервисами в Upstart. В sysVinit всё было понятно - смотришь какие симплинки в каталоге /etc/rc*.d, а там или редактируешь их самостоятельно или воспользуешься утилитами update-rc.d или chkconfig. В systemd есть утилита systemctl, но чтобы узнать какие сервисы можно отключать, не нарушая целостность системы, можно глянуть на симплинки в каталоге /etc/systemd/system/multi-user.target.wants. А вот как это обстоит в upstart я так и не понял. Есть утилита initctl, но в ней нет опций enable, disable.

Бессистемно как-то этот upstart устроен: параметры передаются через параметры ядра, для просмотра статусов есть утилита initctl, но глубокое копание в сервисах осуществляется не утилитой, а ручным редактированием юнитов. Кстати из какого мана информация о параметрах взята? Хотелось бы узнать обо всех параметрах.

Большого man'а по upstart не знаю, есть http://upstart.ubuntu.com/cookbook .

2. но ведь событием может быть в том числе и изменение стейта других джоб. Или вопрос не про это?

Я сам не совсем понял про что вопрос. Моё мнение, что ТС спрашивал про аналог ″systemctl enable SERVICE″ в upstart. В случае с systemd у юнитов чётко прописаны зависимости и команда ″systemctl enable/disable″, если я не путаю, отслеживает их и включает/выключает зависимые юниты.

В случае с upstart такой явной зависимости нет, поэтому и нет команды, которая бы включала/выключала юниты. Там нужно редактировать файл с описанием юнита (задачи).

Хотя, может быть ТС под «включением» подразумевал «старт» (″systemctl start SERVICE″)...

http://askubuntu.com/questions/19320/how-to-enable-or-disable-services

Я сам не совсем понял про что вопрос. Моё мнение, что ТС спрашивал про аналог ″systemctl enable SERVICE″ в upstart. В случае с systemd у юнитов чётко прописаны зависимости и команда ″systemctl enable/disable″, если я не путаю, отслеживает их и включает/выключает зависимые юниты.

В случае с upstart такой явной зависимости нет, поэтому и нет команды, которая бы включала/выключала юниты. Там нужно редактировать файл с описанием юнита (задачи).

Хотя, может быть ТС под «включением» подразумевал «старт» (″systemctl start SERVICE″)...

Я имел в виду то, что имел в виду. То есть под включением я подразумевал «включить» («enable»), а не «запустить» («start»).

А кукбук я тут как раз по диагонали прочитал. Понял не всё правда. Понял, что зависимости юнитов (вернее они в upstart называются задачами «job») всё же есть. Если в задаче jobA прописано

start on starting jobB

2. но ведь событием может быть в том числе и изменение стейта других джоб. Или вопрос не про это?

Ну да.

А относительно того, что лишнее, решайте сами.

Я имел в виду не всё можно назвать лишним. Если я хочу отключить нахрен не нужную службу avahi-daemon, я делаю:

echo manual | sudo tee /etc/init/avahi-daemon.override

Я имел в виду не всё можно назвать лишним.

Совершенно верно, причём это зависит не только от того, есть ли у вас сеть, в которой полезен avahi, но и от версии дистрибутива. То, что в одном дистрибутиве можно отключить без последствий, в вашем может привести к проблемам. Подводные камни в Trusty Tahr я не знаю, и изучать не хочу :)

Крайне странным кажется этот способ после sysVinit, BSD-style init и systemd.

Что странного в редактировании файла? Особоенно для BSD-style init, сколько помню первые слаквари, дак там хочешь что-то установить (какого-нибудь демона), дак сам ковыряй скрипт и ищи место, где его запустить.

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

Параметры init'у какбы и нужно предавать через ядро, он ведь запускается ядром и больше ничего в момент его запуска может и не быть, initrd не обязателен. Вот здесь вот чётко и про --verbose и про то, что через командную строку ядра, даже с объяснением как это сделать в grub'е: http://upstart.ubuntu.com/cookbook/#add-verbose-or-debug-to-the-kernel-comman...

что рунлевелов как таковых нет.

Если я не путаю, то в дебиане их как таковых и не было. Это в RH были различные multiuser — без NFS, с NFS, c X11. А в upstart их не стало как внутренне свойство init-демона, когда runlevel это нечто, о чём знает init, а не просто событие, запускающее цепочку.

А как тогда отключать GUI? Отключением lightdm?

Да, правда, он может запускаться не из lightdm.conf, а из gdm.conf.

А относительно порядка никто не знает, может вам поможет ″man upstart-events″, и изучайте все jobs и условия запуска каждого.

За отсыл к нужным докам спасибо.
Я не курсе я был, что в Debian нет рунлевелов, поскольку всегда устанавливал Debian с netinst-диска или с debootstrap и иксы всегда запускал через startx.
А в слаке всё логично и просто до безобразия. Запускающий скрипт помещаешь в /etc/rc.d, а в /etc/rc.d/rc.M помещаешь конструкцию вида:

if [ -x /etc/rc.d/rc.service ]; then
  . /etc/rc.d/rc.service start
fi

Плохо помню слаку, вроде в 3.3 нифига не было ещё файлов rc.service, там был достаточно большой rc.net, что-ли, где прямо запускались демоны и нужно было комментить несколько строк. Но и в вашем варианте, всё одно нужно вручную редактировать и искать подходящее место для запуска и следить, чтобы не поломать зависимость. Так что редактирование файла — добавление строки manual в *.conf файл или создание *.override файла не должно казаться таким уж странным.

Странным в устройстве upstart вижу то, что нет способа...

Дак он толком не доделаный, ЕМНИП, пока RH (fedora) хотели его пилить, разработчики upstart отпинывались от новых фич, а когда стал подниматся systemd, в upstart что-то стали активно добавлять, только народу сильно поубавилось.