sirve - ¿Cómo implemento un demonio de Python multiplataforma simple?

que es python y para que sirve

Question

Me gustaría que mi programa Python se ejecute en segundo plano como un demonio, en Windows o Unix. Veo que el paquete python-daemon es solo para Unix; ¿Existe alguna alternativa para multiplataforma? Si es posible, me gustaría mantener el código tan simple como pueda.

Answer 1

Dos opciones vienen a la mente:

1. Portar su programa en un servicio de Windows . Probablemente puedas compartir mucho de tu código entre las dos implementaciones.

2. ¿Tu programa realmente usa alguna funcionalidad de demonio? De lo contrario, lo reescribe como un servidor simple que se ejecuta en segundo plano , administra las comunicaciones a través de sockets y realiza sus tareas. Probablemente consumirá más recursos del sistema que un demonio, pero sería independiente de la plataforma de cotización.

Answer 2

En Windows se denomina "servicio" y puede implementarlo con bastante facilidad, por ejemplo, con el módulo win32serviceutil, parte de pywin32 . Desafortunadamente, los dos "modelos mentales", service vs daemon, son muy diferentes en detalle, a pesar de que sirven para propósitos similares, y no conozco ninguna fachada de Python que intente unificarlos en un solo marco.

Answer 3

En general, el concepto de demonio es específico de Unix, en particular el comportamiento esperado con respecto a las máscaras de creación de archivos, la jerarquía de procesos y el manejo de señales.

Puede encontrar útil la PEP 3143 en la que se considera una continuación propuesta de python-daemon para Python 3.2, y se discuten muchos módulos de daemonización relacionados e implementaciones .

Answer 4

Esta pregunta tiene 6 años, pero tuve el mismo problema y las respuestas existentes no fueron lo suficientemente multiplataforma para mi caso de uso. Aunque los servicios de Windows a menudo se usan de manera similar a los demonios de Unix, al final del día difieren sustancialmente, y "el diablo está en los detalles". En pocas palabras, me propuse intentar encontrar algo que me permita ejecutar exactamente el mismo código de aplicación en Unix y Windows, mientras cumplo con las expectativas de un demonio de Unix que se comporte bien (lo que se explica mejor en otro lugar ) lo mejor posible. en ambas plataformas:

1. Cierre los descriptores de archivos abiertos (generalmente todos ellos, pero algunas aplicaciones pueden necesitar proteger algunos descriptores del cierre)
2. Cambie el directorio de trabajo del proceso a una ubicación adecuada para evitar errores de "Directorio Ocupado"
3. Cambie la máscara de creación de acceso a archivos ( os.umask en el mundo Python)
4. Mueva la aplicación a un segundo plano y haga que se desvincule del proceso de inicio.
5. STDERR completamente el terminal, incluida la redirección de STDIN , STDOUT y STDERR a diferentes flujos (a menudo DEVNULL ), y evite la readquisición de un terminal de control
6. Manejar señales, en particular, SIGTERM .

El problema fundamental de la demonización multiplataforma es que Windows, como sistema operativo, realmente no admite la noción de demonio: las aplicaciones que se inician desde un terminal (o en cualquier otro contexto interactivo, incluido el lanzamiento desde Explorer, etc.) continúe ejecutándose con una ventana visible, a menos que la aplicación de control (en este ejemplo, Python) haya incluido una GUI sin ventanas. Además, el manejo de la señal de Windows es lamentablemente inadecuado, y los intentos de enviar señales a un proceso independiente de Python (a diferencia de un subproceso, que no sobreviviría al cierre del terminal) casi siempre darán como resultado la salida inmediata de ese proceso de Python sin ningún tipo de limpieza (no finally: no atexit , no __del__ , etc).

Los servicios de Windows (aunque una alternativa viable en muchos casos) estaban básicamente fuera de la cuestión para mí: no son multiplataforma y requerirán la modificación del código. pythonw.exe (una versión sin ventanas de Python que se incluye con todos los binarios recientes de Windows Python) está más cerca, pero aún no logra el corte: en particular, no mejora la situación para el manejo de la señal, y aún no puede inicie una aplicación pythonw.exe desde el terminal e interactúe con ella durante el inicio (por ejemplo, para entregar argumentos dinámicos de inicio a su script, por ejemplo, una contraseña, una ruta de archivo, etc.) antes de "desemejar".

Al final, decidí usar subprocess.Popen con la palabra clave creationflags=subprocess.CREATE_NEW_PROCESS_GROUP para crear un proceso independiente sin ventanas:

import subprocess

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

Sin embargo, eso aún me dejó con el desafío adicional de las comunicaciones de inicio y el manejo de señales. Sin entrar en un montón de detalles, para el primero, mi estrategia era:

1. pickle las partes importantes del espacio de nombres del proceso de lanzamiento.
2. tempfile en un tempfile
3. Agregue la ruta a ese archivo en el entorno del proceso de la hija antes de iniciar
4. Extraiga y devuelva el espacio de nombres de la función "daemonization"

Para el manejo de la señal tuve que ser un poco más creativo. Dentro del proceso "demonizado":

1. Ignore las señales en el proceso del daemon, ya que, como se mencionó, todas terminan el proceso inmediatamente y sin limpieza.
2. Crear un nuevo hilo para gestionar el manejo de la señal.
3. Ese hilo inicia los procesos de manejo de señales hijas y espera a que se completen
4. Las aplicaciones externas envían señales al proceso de manejo de señales de la hija, lo que hace que finalice y finalice
5. Esos procesos luego usan el número de señal como su código de retorno
6. El hilo de manejo de señales lee el código de retorno y luego llama a un manejador de señales definido por el usuario o usa una API de cytpes para generar una excepción apropiada dentro del hilo principal de Python
7. Enjuague y repita para nuevas señales.

Dicho todo esto, para cualquier persona que se encuentre con este problema en el futuro, he daemoniker una biblioteca llamada daemoniker que envuelve la demonización adecuada de Unix y la estrategia de Windows anterior en una fachada unificada. La API multiplataforma tiene este aspecto:

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()

Answer 5

La razón por la que solo es unix es que los daemons son un concepto específico de Unix, es decir, un proceso en segundo plano iniciado por el sistema operativo y que normalmente se ejecuta como un elemento secundario del PID raíz.
Windows no tiene un equivalente directo de un daemon de Unix, lo más cercano que puedo pensar es un servicio de Windows. Hay un programa llamado pythonservice.exe para windows. No estoy seguro de si es compatible con todas las versiones de python