web-dev-qa-db-fra.com

Le script de démarrage dans / etc / service (runit) ne fonctionne pas avec le démon

J'ai un problème avec un script que j'ai lancé via /etc/service et que j'utilise runit.

Mon script sur /etc/service/myApp/run ressemble à ceci:

#!/bin/bash
cd /src
forever -l forever.log -o out.log -e err.log -a start bin/www

Ce que Forever exécute mon script en tant que démon. Mais cela semble faire croire à Runit que mon service est terminé et qu'il exécute /etc/service/myApp/run encore et encore, et encore et encore ...

J'ai également essayé d'exécuter ceci non en tant que démon et cela fonctionne bien si vous courez au premier plan, mais j'ai toujours un problème. J'ai une commande clean-shutdown à envoyer à mon serveur à un moment donné qui va éventuellement arrêter le processus de premier plan et je ne veux pas qu'il redémarre. Mais à mon grand désarroi, /etc/service/myApp/run est appelé immédiatement pour redémarrer mon serveur :(

Je ne suis pas administrateur système, donc la plupart de ces aspects sont nouveaux pour moi. Tout ce que je veux, c'est que mon script s'exécute au démarrage et non au redémarrage automatique. Merci de votre aide.

EDIT: J'ai mis à jour ma question pour inclure le fait que runit est utilisé ici. Je vois que runit surveille les processus pour maintenir les services. Ma question demeure cependant.

servicesautostartrunit
3
Eric Olson

Ne pas utiliser pour toujours.

C'est très facile. Comme vous l'avez déjà constaté, il est toujours inutile de s'inscrire ici, car runit est déjà un gestionnaire de services et démarre et redémarre déjà votre programme.

Comme vous l'avez déjà observé, il existe quelques règles pour ce que les programmes run doivent faire. Ils ne doivent pas bifurquer et quitter le programme principal. Le gestionnaire de services runit, comme la plupart des gestionnaires de services daemontools-family (il existe toute une famille de logiciels qui fonctionnent de cette manière), s'attend à ce que le processus exécutant le programme run soit le démon. Pas son parent. Pas un bref survol qui fourches et sorties. Mais le démon lui-même.

un simple programme run

Différents langages de script permettent d'écrire de tels programmes run. Laurent Bercot execline est un. Mon programme nosh en est un autre. En supposant que _bin/www_ soit le programme exécutable de votre démon, un script nosh run ressemblerait à quelque chose comme:

#!/bin/nosh 
 fdmove -c 2 1 
 chdir /src
bin/www

Un script execline est pareillement bref. Mais le script Shell n’est plus très long. Si votre programme run est un script Shell, il ne faut pas oublier de superposer le programme Shell avec votre programme de démon dans le même processus. La commande Shell pour cela est exec et un script Shell ressemble donc à quelque chose comme:

#!/bin/sh -e 
 exec 2> & 1 
 cd /src[.____. Printer

Je recommande fortement que, si votre programme ne nécessite pas les privilèges de superutilisateur, vous l'exécutez via le chpst programme (et son option _-u_), afin qu’il commence en tant qu’utilisateur non privilégié - pour de meilleurs résultats, dédié à ce service.

Plusieurs personnes ont rassemblé et publié des suites de programmes run au fil des ans, et la plupart des programmes run sont aussi courts et simples. Puisque vous avez lancé runit, vous pouvez commencer avec la propre collection de programmes run de Gerrit Pape.

démarrage et arrêt de dæmons

Lorsqu’il s’agit de démarrer et d’arrêter le service, encore une fois, il faut demander à la plupart des gestionnaires de services daemontools-family d’arrêter le redémarrage automatique du service. Ils viennent tous avec un outil pour le faire. Il vous suffit de l'utiliser dans votre script _clean-shutdown_.

  • runit a le sv programme: _sv down /etc/service/MyApp_
  • s6 a le s6-svc programme: _s6-svc -d /etc/service/MyApp_
  • perp a le perpctl programme: _perpctl d /etc/service/MyApp_
  • daemontools a le programme svc : _svc -d /etc/service/MyApp_
  • daemontools-encore a le programme svc : _svc -d /etc/service/MyApp_
  • nosh a le service-control programme: _service-control --down /etc/service/MyApp_ qui est également alias svc: _svc -d /etc/service/MyApp_

J'ai dit que c'était une famille d'outils. En fait, sous la couverture, tous ces outils parlent essentiellement du même protocole.

Cela m'amène à un point plus large. Tous ces outils ne sont pas exclusifs. Ce n'est pas parce que vous l'avez lancé que vous utilisez execline si vous le souhaitez. Ou vous pouvez exécuter un script nosh sous le gestionnaire de services de s6.

enregistrement

Vous avez essayé d'écrire des fichiers journaux avec toujours. Encore une fois, n'utilisez pas pour toujours. Ce n'est pas la bonne façon de vous connecter avec runit. La redirection de la sortie standard et des erreurs directement vers les fichiers rend vos journaux impossibles à faire pivoter, à limiter la taille et autrement à contrôler, sans interférence drastique dans le fonctionnement de votre démon.

les gestionnaires de services daemontools-family tous se connectent en ayant la sortie d'un main service connecté, par un tuyau ordinaire, à l'entrée d'un autre service log . Ce canal est configuré par le gestionnaire de service. Tu ne le fais pas toi-même.

Le service de journalisation est un autre service . Il exécute l'un des nombreux outils disponibles qui lisent simplement à partir de son entrée standard et écrivent dans un ensemble de fichiers journaux à rotation à la demande et strictement limités en taille, dans un répertoire de journaux.

Ces programmes sont multilog , multilog , s6-log , tinylog , cyclog , et svlogd lequel est celui que vous allez trouver qui vient dans la boîte à outils avec runit.

En fait, vous remarquerez peut-être que celui qui a configuré _/etc/service/MyApp_ a déjà déjà configuré un service de journalisation dans _/etc/service/MyApp/log_. Sinon, un script de service de journalisation est extrêmement simple:

#!/bin/sh -e 
 exec chpst -uMyApp-log svlogd -t ./main

Créez simplement un compte d'utilisateur nommé _MyApp-log_, _mkdir /etc/service/MyApp/log/main_, _chown MyApp-log /etc/service/MyApp/log/main_ et vous êtes absent. (Notez que main peut être un lien symbolique vers un autre endroit où vous créez le répertoire. Vous n'avez pas besoin de mettre les journaux sous _/etc_ avec runit. J'ai mis mes répertoires de journaux sous _/var/log/sv_.)

Vous ne faites rien du tout à votre service principal de cycle et de journaux de taille maximale. Le cycle et la limitation de taille se produisent indépendamment, dans le processus de service de journal .

Lectures complémentaires

4
JdeBP