Почему мой новомодный сервис не запускается на начальной загрузке системы?

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

pre-start script
  logger "pre-start for myprog"
end script

post-start script
  logger "post-start for myprog"
end script

# and for PMS itself:
script
  logger "just before executing PMS"
  exec /home/administrator/pms-current/PMS.sh
end script

Дополнительную информацию можно найти по адресу http://upstart.ubuntu.com/cookbook/

. / вики / отладка

Вероятно, здесь происходит то, что pms запускается до того, как появятся ваши сетевые адаптеры, и, возможно, даже до появления петлевого адаптера (вот так). Предполагая, что мы говорим о PS3 Media Server, это сетевой сервис, и он, вероятно, не любит запускаться без доступных интерфейсов.

Попробуйте изменить критерии запуска на:

start on filesystem and net-device-up IFACE!=lo

Значение, запуск после запуска любого «реального» сетевого интерфейса. Тем не менее, это может быть не идеально, если eth0 - следующий интерфейс, запускается PMS, но вы действительно хотите, чтобы PMS использовал wlan0, но это не сработает. Служба запустится, но, возможно, ей не удастся выбрать интерфейс, который вы хотите прослушивать. Предполагая, что вы знаете интерфейс, через который вы собираетесь передавать данные, и он не изменится, я бы жестко запрограммировал его в работе, например:

start on filesystem and net-device-up IFACE=wlan0

В Oneiric (11.10) вы можете использовать событие static-network-up ждать всех статически настроенных устройств. Что приятно, потому что позволяет писать сетевые задания без жесткого программирования интерфейса. [Примечание: под «всеми статически настроенными устройствами» я имею в виду использование /etc/network/interfaces вместо NetworkManager. Это не означает статический в смысле статического IP против DHCP.]

После изучения вашего системного журнала процесс pms начинается без ошибок, но затем, через короткое время, его цель меняется с начала на останов, означая, что он убит.

Это немного странно, потому что вы добавили предложение repsawn, поэтому он должен попытаться начать снова после его остановки, но это не происходит. Я предполагаю, что вы удалили пункт о респауне.

Между запуском и остановкой службы pms запускаются только 2 службы ufw и сетевой интерфейс (eth0), а 1 запускается udev-fallback-graphics.

Кажется, что вы обрабатываете pms, запускается параллельно. К сожалению, документация upstart немного неясна относительно точных различий между start on ... vanilla и start on starting ... и start on started ....

Попробуйте изменить раздел запуска на

start on started networking

или просто слишком

start on net-device-up IFACE=eth0

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

Это должно гарантировать, что ваш процесс начинается только после того, как завершена вся настройка сети, т. Е. Задание не только началось, но и завершилось.

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

Я сталкивался с chkconfig во время обучения RHCSA / CE:

sudo apt-get install chkconfig
sudo chkconfig pms on

Вы можете проверить его man-страницу Oneiric для более подробной информации о его возможностях.

Я нашел решение для этого, но я не понимаю его. Если я перенесу PMS из /home/administrator в /bin/pms с владельцем root, все будет работать нормально.

Если я оставлю его в /home/administrator/, но убедитесь, что root является владельцем всего, кроме самого каталога /home/administrator/, он все равно не будет работать.

Если я назначу администратора всем владельцем и изменим соответствующую часть моего сценария на:

sudo su administrator -c '/home/administrator/pms-current/PMS.sh'

Он все еще не работает.

Полагаю, сейчас я создам каталог /home/root/ и перенесу туда все, хотя мне бы очень хотелось это полностью понять.

В моем случае сервис upstart зависел от скрипта, расположенного в vagrant synced folder . Решил проблему, используя следующую строку:

start on vagrant-mounted

Дополнительная информация: http://razius.com/articles/launching-services-after-vagrant-mount/

У меня было подобное, "никакие не запускают" проблему, когда я понял, что мой сценарий зависел от файла, который был в моем доме, и дом не был доступен, потому что был crypted со стандартным механизмом человечности (.Private).

start on local-filesystems событие (вероятно), испускается, прежде чем процесс дешифрования заканчивается.

Подобно @xuhcc, я пришел сюда, чтобы узнать, почему не запускался мой сценарий Vagrant Upstart. Предполагается, что работает следующее:

запускается на монтируемом vagrant

Но не в некоторых сборках из-за следующей ошибки.

https://github.com/mitchellh/vagrant/issues/6074

Обходное решение, перечисленное в отчете, отлично сработало:

$ cat /etc/init/workaround-vagrant-bug-6074.conf 
# workaround for https://github.com/mitchellh/vagrant/issues/6074
start on filesystem
task

env MOUNTPOINT=/vagrant

script
  until mountpoint -q $MOUNTPOINT; do sleep 1; done
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=$MOUNTPOINT
end script

Отлично сработало для меня

это сработало для меня (мне нужно запустить сервис после iface up):

start on started networking and net-device-up IFACE=wlan1 
stop on shutdown

respawn
respawn limit 10 10

Ваш домашний каталог на NFS? Иногда root не может получить доступ к NFS.

Для справки, в моем маленьком тесте только сейчас, 12.04:

• start on started networking и start on network-interface-up INTERFACE=eth0 не работают, но

• start on started network-interface INTERFACE=eth0 делает.

Спасибо http://os4.org/wiki/upstart.html за указание на то, что initctl list всегда показывает работу сети как остановленную.

У меня была та же проблема, и в конце концов я решил ее просто с помощью:

start on runlevel [2345]

без каких-либо net-device-up или started networking вещей

Это полный сценарий выскочки, и он отлично работает:

# MyApp

description     "MyApp"
author          "me"

start on runlevel [2345]
stop on runlevel [016]

respawn

exec /usr/bin/myapp 2>> /var/logs/myapp.log

Удалось исправить подобную проблему, используя вместо этого start on runlevel:

start on runlevel [2345]