Comment faire pour démarrer le processus de démon de python sur windows?

Cette question a été posée il y a 3 ans, et même si les fondamentaux de détails de la réponse n'a pas changé, compte tenu de sa prévalence dans "Windows Python démon" des recherches, j'ai pensé qu'il pourrait être utile d'ajouter un peu de discussion pour le bénéfice des générations futures Google arrivees.

Il y a deux parties à la question:

1. Peut un script Python frayer un processus indépendant qui va s'exécuter indéfiniment?
2. Peut un script Python agir comme un démon Unix sur un système Windows?

La réponse à la première est sans équivoque: oui, comme l'a déjà souligné; à l'aide de subprocess.Popen avec le creationflags=subprocess.CREATE_NEW_PROCESS_GROUP mot suffira:

import subprocess

independent_process = subprocess.Popen(
    'python /path/to/file.py',
    creationflags=subprocess.CREATE_NEW_PROCESS_GROUP
)

Noter que, au moins dans mon expérience, CREATE_NEW_CONSOLE n'est pas nécessaire ici.

Cela étant dit, le comportement de cette stratégie n'est pas tout à fait la même chose que ce que vous attendez d'un démon Unix. Ce qui constitue un bien comportés Unix démon est explique mieux ailleurs, mais pour résumer:

1. Fermer les descripteurs de fichiers ouverts (généralement pour tous, mais certaines applications peuvent avoir besoin pour protéger certains descripteurs de fermeture)
2. Changer le répertoire de travail du processus à un emplacement approprié pour empêcher le "Répertoire Occupé" erreurs
3. Modifier le fichier d'accès création d'un masque (os.umask dans le Python monde)
4. Déplacer l'application en arrière-plan et le faire se désolidariser de l'ouverture de processus
5. Complètement divorce à partir du terminal, y compris la redirection de STDIN, STDOUT, et STDERR à différents cours d'eau (souvent DEVNULL), et de prévenir la ré-acquisition d'un terminal de contrôle
6. Traiter les signaux, en particulier, SIGTERM.

La réalité de la situation est que Windows, comme un système d'exploitation ne supporte pas l'idée d'un démon: les applications qui démarrent à partir d'un terminal (ou dans tout autre contexte interactif, y compris le lancement de l'Explorateur, etc) de continuer à fonctionner avec une fenêtre visible, à moins que l'application de contrôle (dans cet exemple, Python) a inclus une fenêtre de l'interface graphique. En outre, Windows de traitement de signal est très insuffisante, et tente d'envoyer des signaux à un indépendant Python processus (par opposition à un sous-processus, qui ne survivrait pas à la borne de fermeture) sera presque toujours dans l'immédiat, la sortie de Python processus sans nettoyage (pas de finally:, pas de atexit, pas de __del__, etc).

Roulement de votre application dans un service Windows, si une alternative viable dans de nombreux cas, n'a pas également tout à fait adapté. La même chose est vraie de l'aide pythonw.exe (un sans fenêtre de la version de Python qui est livré avec tous les récente de Windows Python binaires). En particulier, ils ne parviennent pas à améliorer la situation pour le traitement du signal, et ils ne peuvent pas facilement lancer une application à partir d'un terminal et d'interagir avec elle pendant le démarrage (par exemple, de livrer dynamique arguments de démarrage de votre script, disons, peut-être, un mot de passe, chemin du fichier, etc), avant "daemonizing". En outre, les services Windows nécessite l'installation, qui, bien que parfaitement possible de le faire rapidement lors de l'exécution lorsque vous appelez vos "démon" -- modifie le système de l'utilisateur de la base de registre, etc), ce qui serait très inattendu, si vous venez d'un monde Unix.

À la lumière de cela, je dirais que le lancement d'un pythonw.exe sous-processus à l'aide de subprocess.CREATE_NEW_PROCESS_GROUP est probablement le plus proche équivalent Windows pour un Python processus d'émuler un Unix traditionnel démon. Cependant, il vous reste le défi supplémentaire de traitement de signal de démarrage et des communications (pour ne pas mentionner faire de votre code qui dépend de la plateforme, ce qui est toujours frustrant).

Cela étant dit, pour ceux qui rencontre ce problème dans le futur, j'ai roulé une bibliothèque appelée daemoniker qui englobe à la fois la bonne Unix daemonization et la stratégie ci-dessus. Il met également en œuvre de traitement de signal (pour Unix et les systèmes Windows), et permet de passer des objets à la "démon" processus à l'aide de cornichon. Le meilleur de tous, il a un croix-plate-forme de l'API:

from daemoniker import Daemonizer

with Daemonizer() as (is_setup, daemonizer):
    if is_setup:
        # This code is run before daemonization.
        do_things_here()

    # We need to explicitly pass resources to the daemon; other variables
    # may not be correct
    is_parent, my_arg1, my_arg2 = daemonizer(
        path_to_pid_file,
        my_arg1,
        my_arg2
    )

    if is_parent:
        # Run code in the parent after daemonization
        parent_only_code()

# We are now daemonized, and the parent just exited.
code_continues_here()