cURL via cronjobs zonder timeout.
Wat gebeurt er met de processen als je een veel gedraaide cronjob draait (elke vijf minuten, direct naar php, geen wget) met een PHP-script die een curl-request doet, die vervolgens blijft wachten op een request. Hoelang blijven deze instances bestaan? En wat als je de webserver of PHP-FPM een reboot geeft? Gaan die instances dan ook allemaal gekilld worden, of moet je dan je hele server even een reboot geven?
Een tip voor een ieder die meeleest: Gebruik een timeout in je curl:
Code (php)
1
2
3
4
2
3
4
<?php
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
curl_setopt($ch, CURLOPT_TIMEOUT, 10); //timeout in seconden, 0 is oneindig
?>
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
curl_setopt($ch, CURLOPT_TIMEOUT, 10); //timeout in seconden, 0 is oneindig
?>
Gewijzigd op 05/06/2019 14:48:56 door - Ariën -
En als je niets doet met een response, waarom zou je hier dan op wachten? Volgens mij zijn er opties om enkel het request te doen, zonder op een response te wachten.
Dan is het zaak dat je ook een mechanisme hebt dat detecteert wanneer een cron (niet) is uitgevoerd, anders heb je wellicht niet in de gaten dat er dingen misgaan. Maar dat is een apart probleem, met een aparte oplossing.
Ik neem aan dat je een cURL-request naar een externe bron doet? Zijn er geen andere/betere manieren om dit te doen?
En wat ben je precies aan het doen? Roep je een webservice aan? Of ben je aan het scrapen?
Maar wat gebeurt er met die instances dan die eindeloos doordraaien als de webservice niet reageert? Gaan die een keer toch gekilld worden, of blijven die draaien totdat de server gerestart wordt?
een script als
zal dan ook eindeloos blijven door draaien.
PHP zou dan ook op een curl-request eindeloos kunnen blijven wachten als die niet zelf een (fatal) error opwekt na verloop van tijd.
Dus ja: als dat niet de bedoeling is, zou een timeout op je curl request handig zijn.
Zeker bij de connectie zou je een timeout moeten instellen. Hoe lang je vervolgens wilt wachten op de output van de remote server als je je request gedropt hebt, is een andere timeout.
dus als
aap.php =
dan zal
$ php aap.php &
je script starten en dat draait door. (in dit geval zal hij stoppen als de user uitlogt, maar in geval van een cronjob, is dat niet van toepassing).
Je kunt dan met bijvoorbeeld
$ pkill -f aap.php
je script stoppen. Of eerst uitzoeken welke Process ID je moet hebben als er meerdere instanties van dat script draaien. En dan kun je "kill" gebruiken.
Je script stopt, los van onder dwang van "kill"
* als de uitvoering klaar is (einde script)
* er exit() of die() wordt aangeroepen
* er een fatale fout optreedt.
En aangezien er geen timeout van toepassing is, komt een fatale fout niet voort uit een teveel gebruik aan tijd. En ook wbt Memory zou je je bewust moeten zijn van de risico's. Ik vraag me af wat daar de limieten zijn.
Dit vond ik wat interressanter, om meteen het geheugenverbuik te zien. Grep op PHP had ook gekund, maar ik toch liever even wat meer zien... ;-)
Als je dan ook nog database-bewerkingen uitvoert die niet in een transactie staan dan wordt dat al snel een grote puinhoop. Waarschijnlijk wil je dat te allen tijde maximaal één zo'n script actief is. In dat geval wil je een soort van semafoor inbouwen die dit garandeert.
Ook zou je natuurlijk kunnen kijken naar efficiëntie, een ruimere periode voor de uitvoering van een "run", en eventueel meer sensoren (of op zijn minst een log) die de uitvoer in de gaten houden.
Maar nog belangrijker is: Waarom krijg ik een time-out. Blijkbaar blokkeert de webservice mij?
Log je een response? Die kan wellicht meer info geven.
Of wellicht strandt het schip eerder, kun je de service wel bereiken?
Gewijzigd op 05/06/2019 22:38:55 door Thomas van den Heuvel
En uiteraard nu in de curl-request een timeout meegegeven. Later ga ik even een semafoor inbouwen die dit beter logt.