web-dev-qa-db-fra.com

Pourquoi mon service upstart ne démarre-t-il pas au démarrage du système?

Après cette question , j’ai écrit un simple service de démarrage (/ etc/init/pms.conf) pour ma boîte sans tête Ubuntu Server 11.04 comme suit:

start on filesystem and net-device-up IFACE=eth0
stop on runlevel [016]
respawn

exec /home/administrator/pms-current/PMS.sh

Je peux démarrer (ou arrêter) ce service à volonté depuis la ligne de commande:

service pms start

Et je peux voir que cela fonctionne vraiment.

Cependant, lorsque je démarre pour la première fois ma machine, le service ne démarre pas. Si je SSH dans la boîte et vérifier l'état du service, je reçois:

$ service pms status
pms stop/waiting

Ma question est pourquoi cela se produit-il? Pourquoi mon service ne démarre-t-il pas?

UPDATE 1 : ne sachant pas si mon service était démarré et par la suite en train de mourir ou si ce n'était tout simplement pas le cas, j'ai ajouté ce qui suit à PMS.sh:

echo "STARTED" > $STARTLOG

Cela me donne évidemment quelque chose à rechercher. J'ai testé cela en démarrant le service moi-même, puis en vérifiant start.log. J'ai ensuite supprimé le start.log et redémarré. Il n'était pas là après le redémarrage, il semble donc que Upstart ne démarre pas mon service. Je suppose que cela pourrait être en train de mourir plus tôt dans le processus, mais cela semble plutôt improbable étant donné la simplicité de tout cela.

UPDATE 2 : Je viens de passer à la version 11.10, ce qui inclut une mise à niveau upstart, mais le problème persiste.

UPDATE 3 : Comme demandé, j'ai démarré avec --debug. La sortie de cat /var/log/syslog | grep init est trop longue pour être placée dans la question, mais vous la consultez ici .

UPDATE 4 : Plus de journaux, cette fois, la conférence par défaut est incluse en haut. Run 1 et run 2 .

bootserverupstart
37
Kent Boogaart

Je recommanderais d'augmenter la verbosité du travail, par exemple en utilisant des entrées pré-start/post-start.

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

Plus d'informations sur http://upstart.ubuntu.com/cookbook/

Regardez aussi http://upstart.ubuntu.com/wiki/Debugging

19
Clausi

Ce qui se passe probablement ici, c'est que pms commence avant que vos adaptateurs réseau ne soient disponibles et probablement avant même l'adaptateur de bouclage (lo). En supposant que nous parlions du serveur multimédia PS3, il s’agisse d’un service en réseau qui n’aime probablement pas le démarrage sans interfaces disponibles.

Essayez de changer votre critère de départ pour:

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

Cela signifie que vous devez démarrer après la mise en place d’une interface réseau "réelle". Cependant, cela pourrait ne pas être idéal, si eth0 est la prochaine interface, PMS démarre, mais vous voulez vraiment que PMS utilise wlan0, cela ne fonctionnera pas. Le service va démarrer mais il n'a peut-être pas été en mesure de choisir l'interface sur laquelle vous souhaitez l'écouter. En supposant que vous connaissiez l'interface sur laquelle vous allez diffuser et qu'elle ne changera pas, je la coderais en dur dans le travail, par exemple:

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

Sur Oneiric (11.10), vous pouvez utiliser l'événement static-network-up pour attendre tous les périphériques configurés de manière statique. Ce qui est bien, car cela vous permet d'écrire des tâches dépendant du réseau sans coder en dur une interface. [Remarque: par "tous les périphériques configurés de manière statique", je parle d'utiliser /etc/network/interfaces au lieu de NetworkManager. Cela ne signifie pas statique dans le sens d'une adresse IP statique par rapport à DHCP.]

14
Mark Russell

J'ai eu le même problème et finalement je l'ai résolu simplement avec:

start on runlevel [2345]

sans aucun net-device-up ou started networking

Ceci est le script de démarrage complet, et cela fonctionne parfaitement:

# MyApp

description     "MyApp"
author          "me"

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

respawn

exec /usr/bin/myapp 2>> /var/logs/myapp.log
3
Daniele B

Géré pour résoudre un problème similaire en utilisant start on runlevel à la place:

start on runlevel [2345]
3
Laurynas

En examinant votre syslog, le processus pms commence sans erreur, mais peu de temps après, son objectif est modifié, ce qui signifie qu'il est tué.

Ceci est un peu étrange car vous avez ajouté la clause repsawn, elle devrait donc recommencer après avoir été arrêtée, mais ce n’est jamais le cas. Je suppose donc que vous avez supprimé la clause de réapparition.

Entre le démarrage et l'arrêt du service pms, seuls 2 services sont démarrés avec ufw et l'interface réseau (eth0), et 1 est lancé avec udev-fallback-graphics.

Il semble que votre processus pms soit démarré en parallèle. Malheureusement, la documentation fournie est un peu floue sur les différences exactes entre start on ... Vanilla et start on starting ... et start on started ....

Essayez de changer votre strophe de démarrage à

start on started networking

ou juste aussi

start on net-device-up IFACE=eth0

La sortie du journal est légèrement étrange, car l'événement net-device-up survient beaucoup plus tard, mais pms démarre avant.

Cela devrait vous assurer que votre processus ne démarre qu'une fois , la configuration de la mise en réseau est terminée, c'est-à-dire que le travail a non seulement commencé, mais est terminé.

De plus, n'approuvez pas complètement la sortie du journal. Au début du processus de démarrage, la journalisation de la sortie dans un fichier ne fonctionne pas toujours. Voir la réponse dans Debugging Upstart

3
Ciaran Liedeman

J'ai trouvé une solution pour cela mais je ne la comprends pas. Si je déplace PMS hors de /home/administrator et dans /bin/pms avec la racine en tant que propriétaire, tout fonctionne correctement.

Si je le laisse sous /home/administrator/ mais que la racine est le propriétaire de tout, à l'exception du répertoire /home/administrator/ lui-même, cela ne fonctionne toujours pas.

Si je configure l'administrateur en tant que propriétaire de tout et modifie la partie pertinente de mon script en:

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

Cela ne fonctionne toujours pas.

Je suppose que pour le moment je vais créer un répertoire /home/root/ et y déplacer tout, même si j'aimerais bien comprendre cela à fond.

1
Kent Boogaart

Votre répertoire personnel est-il sur NFS? Parfois, root ne peut pas accéder à NFS.

Pour mémoire, dans mon petit test du 12.04:

  • start on started networking et start on network-interface-up INTERFACE=eth0 ne fonctionnent pas, mais

  • start on started network-interface INTERFACE=eth0 fait.

Merci à http://os4.org/wiki/upstart.html pour avoir signalé que initctl list indique toujours que le réseau de travail est: arrêté.

1
user94311

J'ai rencontré chkconfig lors de ma formation à RHCSA/CE:

Sudo apt-get install chkconfig
Sudo chkconfig pms on

Vous pouvez vérifier que c'est Oneiric page de manuel pour plus de détails sur ses capacités.

1
Oxwivi

J'ai eu un problème similaire "pas de départ" quand j'ai réalisé que mon script dépendait d'un fichier qui se trouvait chez moi et que la maison n'était pas accessible car elle était cryptée avec le mécanisme standard ubuntu (.Private).

L'événement start on local-filesystems est (probablement) émis avant la fin du processus de déchiffrement.

1
alessandro

Semblable à @xuhcc, je suis venu ici pour savoir pourquoi mon script Vagrant Upstart ne fonctionnait pas. Ce qui suit est censé fonctionner:

commencer sur vagabond monté

Mais pas dans certaines versions en raison du bogue suivant.

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

La solution de contournement indiquée dans le rapport a parfaitement fonctionné pour moi:

$ 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

A bien fonctionné pour moi

0
Ian E

cela a fonctionné pour moi (j'ai besoin de démarrer le service après iface up):

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

respawn
respawn limit 10 10
0
MSS

Dans mon cas, le service upstart dépend du script situé dans le dossier vagrant synchronisé . Résolu le problème en utilisant la ligne suivante:

start on vagrant-mounted

Plus d'infos: http://razius.com/articles/launching-services-after-vagrant-mount/

0
xuhcc