69 votes

Python script comme service/daemon linux

Bonjour,

J'essaie de laisser un python script s'exécuter en tant que service (daemon) sur (ubuntu) linux.

Sur le web, il existe plusieurs solutions comme :

http://pypi.python.org/pypi/python-daemon/

Un processus de démon Unix qui se comporte bien est difficile à mettre en place, mais les étapes requises sont pratiquement les mêmes pour tous les programmes de démon. Une instance DaemonContext contient le comportement et l'environnement de processus configuré pour le programme ; utilisez l'instance comme gestionnaire de contexte pour entrer dans un état de démon.

http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/

Cependant comme je veux intégrer mon script python spécifiquement avec ubuntu linux ma solution est une combinaison avec un script init.d.

#!/bin/bash

WORK_DIR="/var/lib/foo"
DAEMON="/usr/bin/python"
ARGS="/opt/foo/linux_service.py"
PIDFILE="/var/run/foo.pid"
USER="foo"

case "$1" in
  start)
    echo "Starting server"
    mkdir -p "$WORK_DIR"
    /sbin/start-stop-daemon --start --pidfile $PIDFILE \
        --user $USER --group $USER \
        -b --make-pidfile \
        --chuid $USER \
        --exec $DAEMON $ARGS
    ;;
  stop)
    echo "Stopping server"
    /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose
    ;;
  *)
    echo "Usage: /etc/init.d/$USER {start|stop}"
    exit 1
    ;;
esac

exit 0

et en python :

import signal
import time
import multiprocessing

stop_event = multiprocessing.Event()

def stop(signum, frame):
    stop_event.set()

signal.signal(signal.SIGTERM, stop)

if __name__ == '__main__':
    while not stop_event.is_set():
        time.sleep(3)

Ma question est maintenant de savoir si cette approche est correcte. Dois-je gérer des signaux supplémentaires ? Sera-t-il un "processus démon Unix bien élevé" ?

87voto

rlotun Points 3995

En supposant que votre démon ait un moyen de fonctionner en permanence (une boucle d'événements, une torsion, peu importe), vous pouvez essayer d'utiliser upstart .

Voici un exemple de configuration upstart pour un hypothétique service Python :

description "My service"
author  "Some Dude <blah@foo.com>"

start on runlevel [234]
stop on runlevel [0156]

chdir /some/dir
exec /some/dir/script.py
respawn

Si vous sauvegardez ceci comme script.conf pour /etc/init vous pouvez simplement faire une

$ sudo initctl reload-configuration
$ sudo start script

Vous pouvez l'arrêter avec stop script . Ce que le conf upstart ci-dessus dit est de démarrer ce service au redémarrage et aussi de le redémarrer s'il meurt.

En ce qui concerne le traitement des signaux, votre processus devrait naturellement répondre à SIGTERM . Par défaut, cela devrait être géré, à moins que vous n'ayez spécifiquement installé votre propre gestionnaire de signaux.

9voto

Ross R Points 448

La réponse de Rloton est bonne. Voici un léger raffinement, juste parce que j'ai passé une tonne de temps à déboguer. Et je dois faire une nouvelle réponse pour pouvoir formater correctement.

Quelques autres points qui m'ont pris une éternité à déboguer :

  1. Lorsqu'il échoue, vérifiez d'abord /var/log/upstart/.log
  2. Si votre script met en œuvre un démon avec python-daemon vous ne devez PAS utiliser la strophe 'expect daemon'. Ne pas avoir de 'expectation' fonctionne. Je ne sais pas pourquoi. (Si quelqu'un le sait, merci de le signaler).
  3. Aussi, continuez à vérifier "initctl status script" pour vous assurer que vous êtes en place (démarrage/exécution). (et faites un rechargement quand vous mettez à jour votre fichier de conf)

Voici ma version :

description "My service"
author  "Some Dude <blah@foo.com>"

env PYTHON_HOME=/<pathtovirtualenv>
env PATH=$PYTHON_HOME:$PATH

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

chdir <directory>

# NO expect stanza if your script uses python-daemon
exec $PYTHON_HOME/bin/python script.py

# Only turn on respawn after you've debugged getting it to start and stop properly
respawn

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X