Parece que está intentando iniciar procesos de ejecución prolongada desde un servidor web y luego realizar un seguimiento de esos procesos en una base de datos. Eso no es imposible, pero no es una práctica recomendada.
El principal problema es que una solicitud HTTP debe estar siendo manejada actualmente en su servidor web para que realmente haga cualquier cosa (incluidos los procesos de seguimiento que se ejecutan en el sistema), necesita algo que pueda ejecutarse todo el tiempo...
En cambio, una mejor idea sería tener otro proceso de "administrador" demonizado (como mencionas Perl, ese sería un buen lenguaje para escribirlo) generar y rastrear las tareas de ejecución prolongada (por PID y señales), y para eso proceso para actualizar su base de datos SQL.
Luego puede hacer que su proceso de "administrador" escuche las solicitudes para iniciar un nuevo proceso desde su servidor web. Hay varios mecanismos de IPC que podría utilizar. (por ejemplo:señales, SysV shm, sockets de dominio unix, colas en proceso como ZeroMQ, etc.).
Esto tiene múltiples beneficios:
- Si sus secuencias de comandos generadas deben ejecutarse con aislamiento basado en usuarios/grupos (ya sea del sistema o entre sí), entonces su servidor web no necesita ejecutarse como raíz ni configurarse.
- Si un proceso generado "falla", se enviará una señal al proceso "administrador", para que pueda rastrear las ejecuciones incorrectas sin problemas.
- Si usa colas en proceso (p. ej., ZeroMQ) para entregar solicitudes al proceso "administrador", puede "acelerar" las solicitudes del servidor web (para que los usuarios no puedan causar D.O.S. intencionalmente o accidentalmente).
- Ya sea que el proceso generado termine bien o no, no necesita una solicitud HTTP 'activa' al servidor web para actualizar su base de datos de seguimiento.
En cuanto a si algo que debería estar corriendo está corriendo, eso realmente depende de tu semántica. (es decir, ¿se basa en un tiempo de ejecución conocido? ¿Se basa en los datos consumidos? etc.).
La comprobación de si es correr puede ser doble:
- El proceso "administrador" actualiza la base de datos según corresponda, incluido el PID generado.
- El código alojado de su servidor web puede enumerar procesos para determinar si el PID en la base de datos es realmente funcionando, ¡e incluso cuánto tiempo ha estado haciendo algo útil!
La comprobación de si es no ejecutar tendría que estar basado en la convención:
- Nombre los procesos generados algo que pueda predecir.
- Obtenga una lista de procesos para determinar lo que aún se está ejecutando (¿desaparecido?) que no debería estarlo.
En cualquier caso, puede informar a los usuarios que solicitaron que se generaran los procesos y/o hacer algo al respecto.
Un enfoque podría ser tener un trabajo CRON que lea de la base de datos SQL y haga ps para determinar qué procesos generados deben reiniciarse y luego vuelve a solicitar que el proceso "administrador" lo haga utilizando el mismo mecanismo IPC utilizado por el servidor web. Tú decides cómo diferenciar los inicios frente a los reinicios en tu seguimiento/supervisión/registro.
Si el servidor se queda sin energía o se bloquea, puede hacer que el proceso "administrador" realice una limpieza cuando se ejecute por primera vez, por ejemplo:
- Busque entradas en la base de datos para los procesos generados que supuestamente se estaban ejecutando antes de que se apagara el servidor.
- Verifique esos procesos por PID y tiempo de ejecución (esto es importante).
- O bien vuelva a generar los procesos generados que no se completaron, o almacene algo en la base de datos para indicarle al servidor web que este fue el caso.
Actualización n.º 1
Según su comentario, aquí hay algunos consejos para comenzar:
Mencionaste perl, así que suponiendo que tengas algo de competencia allí, aquí hay algunos módulos de perl para ayudarte a escribir el script del proceso "administrador":
Si aún no está familiarizado con él, CPAN es el repositorio de módulos perl que hacen básicamente cualquier cosa.
Daemon::Daemonize - Para demonizar el proceso para que continúe ejecutándose después de cerrar la sesión. También proporciona métodos para escribir secuencias de comandos para iniciar/detener/reiniciar el daemon.
Proc::Spawn
- Ayuda con los scripts secundarios de 'desove'. Básicamente hace fork() entonces exec() , pero también maneja STDIN/STDOUT/STDERR (o incluso tty) del proceso secundario. Puede usar esto para iniciar sus scripts perl de ejecución prolongada.
Si el código front-end de su servidor web aún no está escrito en perl, necesitará algo que sea bastante portátil para el paso de mensajes entre procesos y la cola; Probablemente convertiría el front-end de su servidor web en algo fácil de implementar (como PHP).
Aquí hay dos posibilidades (hay muchas más):
- Perl y PHP implementaciones para el Spread Toolkit .
- Perl y PHP implementaciones para ZeroMQ biblioteca.
Proc::ProcessTable - Puede usar esta verificación en procesos en ejecución (y obtener todo tipo de estadísticas como se mencionó anteriormente).
Hora::HiRes - Use las funciones de tiempo de alta granularidad de este paquete para implementar su marco de trabajo de "limitación". Básicamente, limite la cantidad de solicitudes que elimina de la cola por unidad de tiempo.
DBI (con mysql ) - Actualice su base de datos MySQL desde el proceso "administrador".
