[PHP] Probleem met time_limit vanuit crontab *

[Fugitive1977]

Ik heb een (voor mij) lastig probleem, waarvoor iemand wellicht al een oplossing heeft gevonden.

Ik heb XML bestanden die ik m.b.v. PHP wil verwerken, en de uitkomsten sla ik op in een MySQL database.
Opzich werkt alle code prima, maar nu het probleem, de XML bestanden worden in een bebaalde directory geplaatst, en het verwerken in PHP roep ik aan met een CRON taak zodat er geen browser bij de verwerking aan de pas hoeft te komen.

Voor kleine bestanden werk alles nog goed, maar als de bestanden groter worden, en dus langer nodig hebben om te verwerken, krijg ik te maken met time-out problemen (Time limit exceeded, etc)

Ik heb alle (voor mij) logische stappen ondernomen om dit probleem op te lossen:
zoals php.ini aanpassen en de max_execution_time verhoogt
en set_time_limit( 20 * 3600 ); in het php script op te nemen.
Het vervelende is echter dat het script om de e.o.a. reden in "safe-mode" wordt uitgevoerd vanuit de cron-taak, en daar door de time limits niet beinvloed kunnen worden vanuit php.ini of het script zelf (met set_time_limit)

[Fugitive1977]

Beste mod ik heb vergeten een duidelijke titel te bedenken, maar kan dat nu niet meer aanpassen . . .

[RobIII]

Fugitive1977 schreef op vrijdag 10 oktober 2008 @ 11:15:
Beste mod ik heb vergeten een duidelijke titel te bedenken, maar kan dat nu niet meer aanpassen . . .

Als je dan meteen een suggestie doet dan hoeven wij er geen uit de duim te zuigen. Overigens hebben we daar een TopicReport voor ( )

Overigens lijkt me dit niet echt een PRG probleem maar eerder iets voor WSS ofzo (ik vermoed dat 't ligt aan de user waaronder de cronjob draait ofzo).

[ Voor 23% gewijzigd door RobIII op 10-10-2008 11:17 ]

[Fugitive1977]

[PHP] Probleem met time_limit vanuit crontab . . .

RobIII schreef op vrijdag 10 oktober 2008 @ 11:15:
[...]

Als je dan meteen een suggestie doet dan hoeven wij er geen uit de duim te zuigen. Overigens hebben we daar een TopicReport voor ( [afbeelding] )

Overigens lijkt me dit niet echt een PRG probleem maar eerder iets voor WSS ofzo (ik vermoed dat 't ligt aan de user waaronder de cronjob draait ofzo).

[supakeen]

De PHP Command Line Interface maakt vaak gebruik van een aparte php.ini. Heb je daar al eens gekeken?

[McKaamos]

Fugitive1977 schreef op vrijdag 10 oktober 2008 @ 11:14:
Ik heb een (voor mij) lastig probleem, waarvoor iemand wellicht al een oplossing heeft gevonden.

Ik heb XML bestanden die ik m.b.v. PHP wil verwerken, en de uitkomsten sla ik op in een MySQL database.
Opzich werkt alle code prima, maar nu het probleem, de XML bestanden worden in een bebaalde directory geplaatst, en het verwerken in PHP roep ik aan met een CRON taak zodat er geen browser bij de verwerking aan de pas hoeft te komen.

Voor kleine bestanden werk alles nog goed, maar als de bestanden groter worden, en dus langer nodig hebben om te verwerken, krijg ik te maken met time-out problemen (Time limit exceeded, etc)

Ik heb alle (voor mij) logische stappen ondernomen om dit probleem op te lossen:
zoals php.ini aanpassen en de max_execution_time verhoogt
en set_time_limit( 20 * 3600 ); in het php script op te nemen.
Het vervelende is echter dat het script om de e.o.a. reden in "safe-mode" wordt uitgevoerd vanuit de cron-taak, en daar door de time limits niet beinvloed kunnen worden vanuit php.ini of het script zelf (met set_time_limit)

Dan maak je toch een .htaccess aan? Of je past de bestaande aan.

Zet je er regeltjes in als deze:
php_value max_execution_time 72000
php_value memory_limit 128M
php_flag safe_mode off

etc etc...

Dat werkt natuurlijk alleen als je de cron via de web-url het script laat oproepen.

[ Voor 3% gewijzigd door McKaamos op 10-10-2008 11:20 ]

[doeternietoe]

Als je vanuit de CLI php uitvoert, dan kun je een aparte php.ini meegeven of bepaalde waarden veranderen.

-a Run interactively
-c <path>|<file> Look for php.ini file in this directory
-n No php.ini file will be used
-d foo[=bar] Define INI entry foo with value 'bar'

http://nl3.php.net/features.commandline

[orf]

Hoe roept je cron het php script aan? php commandline of via bijvoorbeeld wget?
Als dat laatste het geval is: switchen naar het eerste.

[Fugitive1977]

oi, nee ik wist niet van het bestaan daarvan, waar vind ik die normaal op een red-hat systeem??
Als ik een "locate php.ini" invoer krijg ik alleen /etc/php.ini

Charlie Murphy schreef op vrijdag 10 oktober 2008 @ 11:19:
De PHP Command Line Interface maakt vaak gebruik van een aparte php.ini. Heb je daar al eens gekeken?

[Fugitive1977]

Ik roep 'm nu aan met "php schrptnaam.php" maar via wget is wellicht ook een optie om de "safe_mode" te omzeilen.

Bedankt voor alle tips hierboven, ik ga alles proberen, en zal de werkende oplossing hier terug-posten . . .

orf schreef op vrijdag 10 oktober 2008 @ 11:21:
Hoe roept je cron het php script aan? php commandline of via bijvoorbeeld wget?
Als dat laatste het geval is: switchen naar het eerste.

[doeternietoe]

Fugitive1977 schreef op vrijdag 10 oktober 2008 @ 11:22:
oi, nee ik wist niet van het bestaan daarvan, waar vind ik die normaal op een red-hat systeem??
Als ik een "locate php.ini" invoer krijg ik alleen /etc/php.ini


[...]

Met deze switch vind je de php.ini:

code:

--ini

[Fugitive1977]

de -c optie gebruik ik wel, maar laat ik naar /etc/php.ini verwijzen (degene die apache normaal ook gebruikt)

doeternietoe schreef op vrijdag 10 oktober 2008 @ 11:21:
Als je vanuit de CLI php uitvoert, dan kun je een aparte php.ini meegeven of bepaalde waarden veranderen.


[...]

http://nl3.php.net/features.commandline

[Fugitive1977]

ik heb nu de aanroep: /usr/bin/php -c/etc/php.ini -q -f cron.php >> /tmp/cron.log &
veranderd naar: wget "http://www.eendomein.nl/cron.php" -O /tmp/cron.log &

Als dat nog niet werkt ga ik maar kijken om lynx of cups te misgebruiken . . .

[RobIII]

Let je ook even op ons topickick binnen 24 uur beleid? Als je als laatste hebt gepost en je wil nog iets toevoegen, gebruik dan de knop.

[trinite_t]

Fugitive1977 schreef op vrijdag 10 oktober 2008 @ 11:38:
ik heb nu de aanroep: /usr/bin/php -c/etc/php.ini -q -f cron.php >> /tmp/cron.log &
veranderd naar: wget "http://www.eendomein.nl/cron.php" -O /tmp/cron.log &

Als dat nog niet werkt ga ik maar kijken om lynx of cups te misgebruiken . . .

Volgens mij ga je het je nu JUIST moeilijk maken. Ik zou het zelf op de volgende manier doen:
het volgende commando in de crontab zetten:

code:

/usr/bin/php -q -d max_execution_time=0 -f cron.php >> /tmp/cron.log &

En anders met -c een aangepaste php.ini meegeven met de instellingen die je wilt gebruiken (waaronder dus een max_execution_time=0).

[ Voor 4% gewijzigd door trinite_t op 10-10-2008 11:53 ]

[Fugitive1977]

Ik geef nu de php.ini aan de -c mee, die altijd wordt gebruikt door apache (/etc/php.ini), op die manier blijven alle instellingen op één centrale plaats, hetgeen mij voor de toekomst handiger lijkt . . .

Maar ieder zijn eigen voorkeur uiteraard . . .

Zoals ik vertelde zal ik de beste werkende oplossing hier posten, helaas zal ik moeten wachten totdat de volgende files verwerkt moeten worden, dat zal begin komende week zijn.

Tot zover bedankt iedereen voor het meedenken en de aangedragen suggesties !

trinite_t schreef op vrijdag 10 oktober 2008 @ 11:51:
[...]


Volgens mij ga je het je nu JUIST moeilijk maken. Ik zou het zelf op de volgende manier doen:
het volgende commando in de crontab zetten:

code:

/usr/bin/php -q -d max_execution_time=0 -f cron.php >> /tmp/cron.log &

En anders met -c een aangepaste php.ini meegeven met de instellingen die je wilt gebruiken (waaronder dus een max_execution_time=0).

[trinite_t]

Fugitive1977 schreef op vrijdag 10 oktober 2008 @ 12:24:
Ik geef nu de php.ini aan de -c mee, die altijd wordt gebruikt door apache (/etc/php.ini), op die manier blijven alle instellingen op één centrale plaats, hetgeen mij voor de toekomst handiger lijkt . . .
[...]

Volgens mij zit daar nu juist het probleem, je wilt een wijziging doorgeven. Dus zul je dat of moeten doen via een andere php.ini (de huidige hoef je niet met -c mee te geven, wordt standaard gebruikt), of via dat -d, en volgens mij is dat voor jou de beste oplossing. Via wget oid is zowieso geen oplossing, dan zit je juist me die restricties (safe mode ed) en op een goed opgezette server kun je de meeste van deze ini variabelen ook echt niet wijzigen door ze in een .htaccess te zetten.
Daar komt nog bij dat je alleen maar extra resources gebruikt door het via apache te laten afhandelen.