Sembra che tu stia tentando di avviare processi di lunga durata da un server Web e quindi tenere traccia di tali processi in un database. Non è impossibile, ma non è una pratica consigliata.
Il problema principale è che una richiesta HTTP deve essere attualmente gestita nel tuo server web perché tu effettivamente fai qualsiasi cosa (inclusi i processi di traccia in esecuzione sul sistema):hai bisogno di qualcosa che possa essere eseguito tutto il tempo...
Invece, un'idea migliore sarebbe quella di avere un altro processo "gestore" demonizzato (come dici perl, sarebbe un buon linguaggio in cui scriverlo) spawn e traccia le attività di lunga durata (tramite PID e segnali), e per quello processo per aggiornare il database SQL.
Puoi quindi fare in modo che il tuo processo "gestore" ascolti le richieste per avviare un nuovo processo dal tuo server web. Ci sono vari meccanismi IPC che potresti usare. (es:segnali, SysV shm, socket di dominio unix, code in-process come ZeroMQ, ecc.).
Questo ha molteplici vantaggi:
- Se gli script generati devono essere eseguiti con isolamento basato su utenti/gruppi (dal sistema o tra di loro), il server web non ha bisogno di essere eseguito come root, né di essere setgid.
- Se un processo generato "si arresta in modo anomalo", verrà inviato un segnale al processo "gestore", in modo che possa tenere traccia delle esecuzioni errate senza problemi.
- Se utilizzi code in-process (es:ZeroMQ) per inviare richieste al processo "manager", questo può "limitare" le richieste dal server web (in modo che gli utenti non possano causare D.O.S intenzionalmente o accidentalmente).
- Indipendentemente dal fatto che il processo generato finisca bene, non è necessaria una richiesta HTTP "attiva" al server Web per aggiornare il database di monitoraggio.
Se qualcosa che dovrebbe essere in esecuzione è in esecuzione, dipende davvero dalla tua semantica. (es:si basa su un tempo di esecuzione noto? basato sui dati consumati? ecc.).
Il controllo se lo è la corsa può essere duplice:
- Il processo "gestore" aggiorna il database in modo appropriato, incluso il PID generato.
- Il codice ospitato del tuo server web può effettivamente elencare i processi per determinare se il PID nel database è effettivamente in esecuzione, e anche quanto tempo è passato facendo qualcosa di utile!
Il controllo per verificare se non la corsa dovrebbe essere basata sulla convenzione:
- Assegna ai processi generati qualcosa che puoi prevedere.
- Ottieni un elenco di processi per determinare cosa è ancora in esecuzione (defunto?) che non dovrebbe essere.
In entrambi i casi, potresti informare gli utenti che hanno richiesto la generazione dei processi e/o effettivamente fare qualcosa al riguardo.
Un approccio potrebbe essere quello di avere un lavoro CRON che legge dal database SQL e fa ps per determinare quali processi generati devono essere riavviati, quindi richiede nuovamente che il processo "gestore" lo faccia utilizzando lo stesso meccanismo IPC utilizzato dal server web. Il modo in cui distingui avvii e riavvii nel monitoraggio/monitoraggio/registrazione dipende da te.
Se il server stesso perde alimentazione o si arresta in modo anomalo, è possibile che il processo "gestore" esegua la pulizia quando viene eseguito per la prima volta, ad esempio:
- Cerca le voci nel database per i processi generati che erano presumibilmente in esecuzione prima che il server venisse spento.
- Controlla quei processi tramite PID e runtime (questo è importante).
- Rigenera i processi generati che non sono stati completati o archivia qualcosa nel database per indicare al server web che era così.
Aggiornamento n. 1
Secondo il tuo commento, ecco alcuni suggerimenti per iniziare:
Hai menzionato il perl, quindi supponendo che tu abbia una certa competenza in questo campo -- ecco alcuni moduli perl che ti aiutano a scrivere lo script del processo "manager":
Se non lo conosci già CPAN è il repository per i moduli perl che fanno praticamente qualsiasi cosa.
Daemon::Daemonize - Per demonizzare il processo in modo che continui a funzionare dopo la disconnessione. Fornisce anche metodi per scrivere script per avviare/arrestare/riavviare il demone.
Proc::Spawn
- Aiuta con script figlio "generazione". Fondamentalmente fa fork() quindi exec() , ma gestisce anche STDIN/STDOUT/STDERR (o anche tty) del processo figlio. Puoi usarlo per avviare i tuoi script Perl di lunga durata.
Se il codice front-end del tuo server web non è già scritto in perl, avrai bisogno di qualcosa che sia abbastanza portatile per il passaggio e l'accodamento dei messaggi tra processi; Probabilmente renderei il front-end del tuo server web in qualcosa di facile da implementare (come PHP).
Ecco due possibilità (ce ne sono molte altro):
Proc::ProcessTable - Puoi utilizzare questo controllo sui processi in esecuzione (e ottenere tutti i tipi di statistiche come discusso sopra).
Time::HiRes - Usa le funzioni temporali ad alta granularità di questo pacchetto per implementare il tuo framework di "throttling". Fondamentalmente limita il numero di richieste che rimuovi dalla coda per unità di tempo.
DBI (con mysql ) - Aggiorna il tuo database MySQL dal processo "manager".
