Python démon et systemd service

J'ai un simple script Python fonctionne comme un démon. Je suis en train de créer systemd script pour pouvoir lancer ce script au démarrage.

Actuel systemd script:

[Unit]
Description=Text
After=syslog.target

[Service]
Type=forking
User=node
Group=node
WorkingDirectory=/home/node/Node/
PIDFile=/var/run/zebra.pid
ExecStart=/home/node/Node/node.py

[Install]
WantedBy=multi-user.target

node.py:

if __name__ == '__main__':
    with daemon.DaemonContext():
        check = Node()
        check.run()

run contient while True boucle.

J'essaie d'exécuter ce service avec systemctl start zebra-node.service. Malheureusement, de services jamais été terminé en indiquant la séquence, je dois appuyer sur Ctrl+C.
Le Script est en cours d'exécution, mais le statut est en cours d'activation et après un moment il changer pour la désactivation.
Maintenant, je suis en utilisant python-démon (mais avant j'ai essayé sans et les symptômes étaient similaires).

Dois-je mettre en œuvre certaines des fonctionnalités supplémentaires à mon script ou est systemd fichier incorrect?

  • N'a la réponse à résoudre votre problème? Si pas, essayez de définir daemon_context=True lors de la création de la DaemonContext(). Il peut fonctionner.
  • C'est dommage, votre code Python exemple n'est pas complète (il manque l'importation de daemon et pas clair, où la Node vient) alors il n'est pas facile/possible de reproduire votre situation.
  • Cette indirectement liés à la question, mais peut vous aider: unix.stackexchange.com/a/226853/33386
InformationsquelleAutor pawelbial | 2012-10-25
  1. 102

    La raison, il ne complète pas la séquence de démarrage, que pour le Type forking votre processus de démarrage est prévu à la fourchette et à la sortie (voir $ man systemd.service de recherche de la fourche).

    Simplement utiliser uniquement le processus principal, ne pas daemonize

    Une option est de faire moins. Avec systemd, il n'est souvent pas nécessaire de créer des démons et vous pouvez exécuter directement le code sans daemonizing.

    #!/usr/bin/python -u
from somewhere import Node
check = Node()
check.run()

    Cela permet à l'aide de simple Type de service appelé simple, de sorte que votre unité fichier devrait ressembler.

    [Unit]
Description=Simplified simple zebra service
After=syslog.target

[Service]
Type=simple
User=node
Group=node
WorkingDirectory=/home/node/Node/
ExecStart=/home/node/Node/node.py
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target

    Noter, que la -u en python arborescence n'est pas nécessaire, mais dans le cas où vous afficher quelque chose à l'stdout ou stderr, la -u permet de s'assurer, il n'y a pas de tampon de sortie en place et de lignes imprimées seront immédiatement attiré par systemd et enregistrés dans le journal. Sans elle, il semblerait, avec un peu de retard.

    Pour cela que j'ai ajouté dans l'unité fichier les lignes StandardOutput=syslog et StandardError=syslog. Si vous ne vous souciez pas de la sortie imprimée dans votre journal, ne se soucient pas de ces lignes (ils n'ont pas à être présent).

    systemd fait daemonization obsolètes

    Alors que le titre de votre question demande explicitement sur daemonizing, je suppose, le cœur de la question est "comment faire mon service en cours d'exécution" et tandis que à l'aide de processus principal semble beaucoup plus simple (vous n'avez pas de soins sur les démons à tous), il pourrait être considéré comme la réponse à votre question.

    Je pense, que beaucoup de gens utilisent daemonizing juste parce que "tout le monde le fait". Avec systemd les raisons pour daemonizing sont souvent obsolètes. Il y a peut être quelques raisons d'utiliser daemonization, mais rares sont les cas maintenant.

    EDIT: fixe python -p bon python -u. grâce kmftzg

    • La raison pour daemonize est à l'appui d'autres plates-formes qui n'utilisent pas de systemd. Avoir à faire un autre chemin d'accès du code de systemd est une autre façon de systemd inhibe la portabilité.
    • et c'est une autre façon de portabilité inhibe progrès & simplification.
    • Je suis sûr que tous les développeurs qui ont écrit des applications en s'appuyant sur les progrès et la simplification du système d'exploitation OS/2 d'accord avec vous.
    • systemd prend en charge la croisée des applications, donc il n'est pas nécessaire pour séparer codepath pour systemd, si vous ne souhaitez pas. Ne pas lire de la documentation inhibe les compétences pratiques et peuvent faire des commentaires sans fondement.
    • Oui, mais votre réponse ne suggère pas cette option - il dit à l'OP de modifier leur code au lieu de leur dire comment le soutien de systemd sans pour autant sacrifier le soutien pour les non-systemd plates-formes. Votre propre réponse suggère "Il y a peut être quelques raisons d'utiliser daemonization, mais rares sont les cas maintenant." et j'ai été contente de commenter l'origine, pourquoi devriez-vous daemonize, puisque vous semble manquer le point.
    • L'OP parle de "simple script python" et l'utilisation de "systemd". Aucune demande de non-systemd plates-formes de portabilité, une telle demande n'existe que dans vos réactions blâmer systemd.
    • FYI – -p n'est pas une chose, mais -u est. Voir docs.python.org/3/using/cmdline.html#cmdoption-u
    • merci @kmftzg - fixe.
    • Il y a clairement d'autres outils de gestion de processus, tels que supervisord ou pm2. Je pensais "pas-à-daemonize" est clairement unix façon de faire les choses.
    • J'ai un travail python démon à l'aide de python-démon modèle standard (basé à celle décrite ici: dpbl.wordpress.com/2017/02/12/a-tutorial-on-python-daemon) et est fonctionne plutôt bien avec et sans systemd. Je viens de commenter les systemd Type de valeur afin de laisser la valeur par défaut. systemd start/stop fonctionne comme prévu: signal d'écoute, ainsi que l'exécution à la main avec --daemon processus: il vérifie pid et d'autres choses importantes, de sorte que vous pouvez daemonize un script python avec quelques lignes et faire systemd compatible. J'utilise systemd pour s'exécuter au démarrage et redémarrage sur vraiment des erreurs inattendues.

    InformationsquelleAutor Jan Vlcinsky
  2. 21

    Il est possible de daemonize comme Schnouki et Amit décrire. Mais avec systemd, ce n'est pas nécessaire. Il y a deux plus agréable des façons d'initialiser le démon: socket-l'activation et la notification explicite avec sd_notify().

    Prise d'activation fonctionne pour les démons qui veulent écouter sur un port réseau ou d'une socket UNIX ou similaire. Systemd ouvrir le socket, écouter, et ensuite lancer le démon lorsqu'une connexion arrive. C'est la meilleure approche, car elle donne plus de souplesse à l'administrateur. [1] et [2] donne une belle introduction, [3] décrit l'API C, tandis que [4] décrit l'API Python.

    [1] http://0pointer.de/blog/projects/socket-activation.html

    [2] http://0pointer.de/blog/projects/socket-activation2.html

    [3] http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html

    [4] http://www.freedesktop.org/software/systemd/python-systemd/daemon.html#systemd.daemon.listen_fds

    Notification explicite signifie que le démon ouvre les prises de lui-même et/ou n'importe quel autre initialisation, puis en informe init qu'il est prêt et peut répondre à des demandes. Cela peut être mis en œuvre avec le "fork de protocole", mais en réalité il est plus agréable de simplement envoyer une notification à systemd avec sd_notify().
    Wrapper Python est appelé à systemd.le démon.informer et aura une ligne à utiliser [5].

    [5] http://www.freedesktop.org/software/systemd/python-systemd/daemon.html#systemd.daemon.notify

    Dans ce cas, l'unité fichier auraient Type=informer, et de les appeler
    systemd.le démon.notify("PRÊT=1") après qu'il a établi les sockets. Pas de bifurquer ou daemonization est nécessaire.

    InformationsquelleAutor zbyszek
  3. 14

    Vous n'êtes pas créer le fichier PID.

    systemd s'attend votre programme pour écrire son PID dans /var/run/zebra.pid. Comme vous ne le faites pas, systemd pense probablement que votre programme est un échec, d'où le désactivant.

    Pour ajouter le fichier PID, installer lockfile et modifiez votre code pour cela:

    import daemon
import daemon.pidlockfile 

pidfile = daemon.pidlockfile.PIDLockFile("/var/run/zebra.pid")
with daemon.DaemonContext(pidfile=pidfile):
    check = Node()
    check.run()

    (Note: certaines récente mise à jour de lockfile changé son API et de fait incompatible avec python-démon. Pour le corriger, modifier daemon/pidlockfile.py, supprimer LinkFileLock par les importations, et d'ajouter from lockfile.linklockfile import LinkLockFile as LinkFileLock.)

    Attention d'une autre chose: DaemonContext change le dossier de travail de votre programme de /, faisant de la WorkingDirectory de votre service de fichiers inutiles. Si vous voulez DaemonContext à chdir dans un autre répertoire, utilisez DaemonContext(pidfile=pidfile, working_directory="/path/to/dir").

    • Le dernier paragraphe sur la façon dont DaemonContext change le répertoire de travail du programme vient d'être résolu mes problèmes daemonzing
    • Depuis moins de code est plus, je préfère la réponse "tout Simplement utiliser seulement le processus principal, ne pas daemonize".
    • idk si l'API a changé dans Python3. mais il doit être import daemon.pidfile et pas import daemon.pidlockfile
    InformationsquelleAutor Schnouki
  4. 3

    Aussi, vous aurez très probablement besoin de définir daemon_context=True lors de la création de la DaemonContext().

    C'est parce que, si python-daemon détecte que si elle est en cours d'exécution en vertu d'un système d'init, il ne veut pas se détacher du processus parent. systemd s'attend à ce que le démon processus en cours d'exécution avec Type=forking va le faire. Par conséquent, vous avez besoin que, d'autre systemd vais garder en attente, et enfin tuer le processus.

    Si vous êtes curieux, dans python-daemons'démon module, vous allez voir ce code:

    def is_detach_process_context_required():
    """ Determine whether detaching process context is required.

        Return ``True`` if the process environment indicates the
        process is already detached:

        * Process was started by `init`; or

        * Process was started by `inetd`.

        """
    result = True
    if is_process_started_by_init() or is_process_started_by_superserver():
        result = False

    J'espère que cela explique mieux.

    • J'ai peut être tort, mais je pense que cet indicateur est appelé "detach_process" pas et ne "daemon_context"
    InformationsquelleAutor
  5. 1

    Je suis tombé sur cette question lors de la tentative de convertir certains python init.d services à systemd sous CentOS 7. Cela semble fonctionner très bien pour moi, par le fait de placer ce fichier dans /etc/systemd/system/:

    [Unit]
Description=manages worker instances as a service
After=multi-user.target

[Service]
Type=idle
User=node
ExecStart=/usr/bin/python /path/to/your/module.py
Restart=always
TimeoutStartSec=10
RestartSec=10

[Install]
WantedBy=multi-user.target

    J'ai ensuite laissé tomber mon ancien init.d fichier de service de /etc/init.d et a couru sudo systemctl daemon-reload pour recharger systemd.

    Je voulais que mon service de redémarrage automatique, donc les options de redémarrage. J'ai aussi trouvé à l'aide de idle pour Type fait plus de sens que simple.

    Comportement de la veille est très similaire à simple; toutefois, l'exécution réelle
    de binaire du service est retardée jusqu'à ce que toutes les tâches actives sont expédiés.
    Cela peut être utilisé pour éviter l'entrelacement de la production de services de shell
    avec la sortie de l'état sur la console.

    Plus de détails sur les options que j'ai utilisé ici.

    J'ai également expérimenté avec le maintien de l'ancien service et avoir systemd resart le service, mais j'ai rencontré quelques problèmes.

    [Unit]
# Added this to the above
#SourcePath=/etc/init.d/old-service 

[Service]
# Replace the ExecStart from above with these
#ExecStart=/etc/init.d/old-service start
#ExecStop=/etc/init.d/old-service stop

    Les problèmes que j'ai rencontré était que l'init.d service de script a été utilisé à la place du service systemd si les deux ont le même nom. Si vous avez tué l'init.d initié le processus, la systemd script seraient alors prendre le relais. Mais si vous avez exécuté service <service-name> stop il renvoie à l'ancien init.d service. J'ai donc trouvé le meilleur moyen était d'abandonner la vieille init.d et le service de commande visé à l'systemd service à la place.

    Espérons que cette aide!

    InformationsquelleAutor radtek