Het lijkt erop dat u langlopende processen vanaf een webserver probeert te starten en die processen vervolgens in een database te volgen. Dat is niet onmogelijk, maar geen aanbevolen praktijk.
Het grootste probleem is dat een HTTP-verzoek momenteel moet worden afgehandeld op uw webserver, want u doet het eigenlijk doe alles (inclusief het volgen van processen die op het systeem draaien) -- je hebt iets nodig dat altijd kan draaien...
In plaats daarvan zou een beter idee zijn om een ander gedemoniseerd "manager"-proces te hebben (zoals je perl noemt, dat zou een goede taal zijn om het in te schrijven) spawn &volg de langlopende taken (door PID en signalen), en daarvoor proces om uw SQL-database bij te werken.
U kunt dan uw "manager"-proces laten luisteren naar verzoeken om een nieuw proces vanaf uw webserver te starten. Er zijn verschillende IPC-mechanismen die u kunt gebruiken. (bijv. signalen, SysV shm, unix-domein sockets, in-process wachtrijen zoals ZeroMQ, etc).
Dit heeft meerdere voordelen:
- Als uw voortgebrachte scripts moeten worden uitgevoerd met op gebruiker/groep gebaseerde isolatie (van het systeem of van elkaar), dan hoeft uw webserver niet als root te worden uitgevoerd en hoeft ook niet setgid te zijn.
- Als een voortgebracht proces "crasht", wordt een signaal afgegeven aan het "manager"-proces, zodat het foutieve uitvoeringen zonder problemen kan volgen.
- Als u in-proces wachtrijen (bijv. ZeroMQ) gebruikt om verzoeken aan het "manager"-proces te leveren, kan het verzoeken van de webserver "afknijpen" (zodat gebruikers niet opzettelijk of per ongeluk D.O.S kunnen veroorzaken). >
- Of het voortgebrachte proces nu wel of niet goed afloopt, je hebt geen 'actief' HTTP-verzoek aan de webserver nodig om je trackingdatabase bij te werken.
Of iets dat moet be running is running, dat ligt echt aan je semantiek. (d.w.z. is het gebaseerd op een bekende looptijd? op basis van verbruikte gegevens? enz.).
De controle of het is hardlopen kan tweeledig zijn:
- Het "manager"-proces werkt de database zo nodig bij, inclusief de voortgebrachte PID.
- De door uw webserver gehoste code kan processen weergeven om te bepalen of de PID in de database eigenlijk is rennen, en zelfs hoeveel tijd het iets nuttigs heeft gedaan!
De controle of het niet . is hardlopen zou gebaseerd moeten zijn op conventie:
- Noem de voortgebrachte processen iets dat je kunt voorspellen.
- Ontvang een proceslijst om te bepalen wat er nog actief is (opgeheven?) dat niet zou moeten zijn.
In beide gevallen kunt u ofwel de gebruikers informeren die hebben verzocht om het opstarten van de processen en/of er daadwerkelijk iets aan doen.
Een benadering zou kunnen zijn om een CRON-taak te hebben die uit de SQL-database leest en ps . doet om te bepalen welke voortgebrachte processen opnieuw moeten worden gestart, en vraagt vervolgens opnieuw dat het "manager"-proces dit doet met hetzelfde IPC-mechanisme dat door de webserver wordt gebruikt. Hoe u onderscheid maakt tussen starten en opnieuw opstarten in uw tracking/monitoring/logging is aan u.
Als de server zelf geen stroom meer krijgt of crasht, kunt u het "manager"-proces een opschoning laten uitvoeren wanneer het voor het eerst wordt uitgevoerd, bijvoorbeeld:
- Zoek naar vermeldingen in de database voor voortgebrachte processen die zogenaamd actief waren voordat de server werd afgesloten.
- Controleer op die processen op PID en runtime (dit is belangrijk).
- Ofwel re-spawn de voortgebrachte processen die niet zijn voltooid, of sla iets op in de database om aan de webserver aan te geven dat dit het geval was.
Update #1
Volgens uw opmerking zijn hier enkele tips om aan de slag te gaan:
Je noemde perl, dus aangenomen dat je daar enige vaardigheid hebt -- hier zijn enkele perl-modules om je op weg te helpen bij het schrijven van het "manager"-processcript:
Als je er nog niet bekend mee bent CPAN is de opslagplaats voor perl-modules die eigenlijk alles kunnen.
Daemon::Daemonize - Om het proces te daemoniseren zodat het blijft draaien nadat u zich afmeldt. Biedt ook methoden voor het schrijven van scripts om de daemon te starten/stoppen/herstarten.
Proc::Spawn
- Helpt bij het 'spawnen' van kindscripts. In principe doet fork() dan exec() , maar behandelt ook STDIN/STDOUT/STDERR (of zelfs tty) van het onderliggende proces. Je zou dit kunnen gebruiken om je langlopende perl-scripts te starten.
Als de front-endcode van je webserver nog niet in perl is geschreven, heb je iets nodig dat redelijk draagbaar is voor het doorgeven van berichten tussen processen en in de wachtrij plaatsen; Ik zou waarschijnlijk de front-end van je webserver maken in iets dat gemakkelijk te implementeren is (zoals PHP).
Hier zijn twee mogelijkheden (er zijn veel meer):
- Perl en PHP implementaties voor de Spread Toolkit .
- Perl en PHP implementaties voor de ZeroMQ bibliotheek.
Proc::ProcessTable - U kunt deze controle gebruiken voor lopende processen (en allerlei statistieken krijgen zoals hierboven besproken).
Time::HiRes - Gebruik de zeer gedetailleerde tijdfuncties van dit pakket om uw 'throttling'-framework te implementeren. Beperk in feite gewoon het aantal verzoeken dat u per tijdseenheid uit de wachtrij haalt.
DBI (met mysql ) - Werk uw MySQL-database bij via het "manager"-proces.