[PHP/Cronjobs] Via shell wel, maar via cronjob niet

[RSD]

Ik wil dagelijks een php script uitvoeren in de nacht die redelijk zwaar is, zwaar in de zin van hij moet een aantal feeds ophalen die redelijk groot zijn en in de database importeren. Ik heb gekozen om dit via een cronjob te doen. Ik heb in de cronjob het volgende staan:

/usr/local/bin/php /home/sites/domein.nl/import.php > /dev/null 2>&1

Als ik via een shell dit commando uitvoer, dan werkt het prima en wordt de database helemaal geupdate.

Als ik de bovenstaande opdracht via een cronjob laat uitvoeren, dan gebeurt er echter niks.

In de cronlogs zie ik dat het commando wel wordt uitgevoerd. Nu is mijn vraag. Zijn er verschillen tussen een commando laten uitvoeren via een cronjob of direct via de shell? De user is overal root. Ik worstel al enige tijd met dit porbleem en kom er zelf niet uit. Zoeken op "difference cronjob shell" en nog een flink aantal andere termen heeft niks opgeleverd.

De cronjob heb ik via webmin ingevoerd en als ik de cronjob aanklik en ik klik op de button "Run now" dan doet hij het ook goed.

Ik plaats dit hier, omdat ikhet vermoeden heb dat het aan php zelf ligt.

[Creepy]

Als je "> /dev/null 2>&1" weghaalt achter je cronjob dan worden eventuele meldingen e.d. opgevangen en gemailed door cron. Heb je dat al geprobeerd zodat je een eventuele foutmelding kan lezen? Als je je import.php kan uitvoeren via de commandline dan zou het ook zonder problemen moeten draaien via cron.

[Tiemez]

Misschien sta je als je het handmatig via de shell in de juiste directory, waardoor relatieve paden kloppen?

Zorg ervoor dat alle paden absoluut zijn vanaf de /

[ Voor 18% gewijzigd door Tiemez op 24-11-2008 10:02 ]

[RSD]

Ik had gelezen ergens dat als er iets geoutput werd door het script, dat hij dan de cron afbreekt, omdat deze geen stdout heeft oid. Het fijne weet ik er niet van, dus vandaar dat ik het erachter had gezet. Maar ik zal het eens weghalen.

[Niemand_Anders]

Dan redirect je de output naar een bestand en controleer je de output van dat bestand '> /tmp/cronjob-import-domein_nl.log'.

[RSD]

De paden zijn allemaal correct en absoluut.

[eamelink]

RSD schreef op maandag 24 november 2008 @ 10:02:
Ik had gelezen ergens dat als er iets geoutput werd door het script, dat hij dan de cron afbreekt, omdat deze geen stdout heeft oid. Het fijne weet ik er niet van, dus vandaar dat ik het erachter had gezet. Maar ik zal het eens weghalen.

Neehoor, cron heeft gewoon een stdout en die wordt gemaild naar de user.

Meestal is het probleem dat je environment variabelen (PATH in het bijzonder) leeg zijn als je als cron je script draait. Die moet je dus weer even vullen, of overal absolute paden gebruiken naar executables en dergelijke.

[Flipke84]

Heb je toevallig includes in je php-file gebruikt?

[IEF]

Gezien dat je cronjob wél draait als je op "Run Now" klikt.. (ik ga er even voor het gemak vanuit dat Webmin dan ook die cronjob start, en niet alleen het commando draait natuurlijk)

Werken je andere cronjobs wel?

En inderdaad even benieuwd wat er precies gebeurt als de cronjob draait (output).

[RSD]

Ik heb er laatst wel een functie bij gezet, die ik ook gebruik, die gebruik maakt van curl. Ik weet niet of dit problemen kan opleveren? Het is net of het sinds die tijd elke keer fout gaat. Het rare is is dat als ik de opdracht via de prompt uitvoer het allemaal vlekkeloos werkt. Vandaar ook dat ik het niet snap, want dit zou in principe hetzelfde moeten zijn.

[RSD]

Ja mijn andere cronjobs werken prima, alleen deze zijn minder zwaar, vandaar dat ik dacht dat er misschien een verschil is tussen een commando uitvoeren via de prompt of via een cronjob.

[ Voor 67% gewijzigd door RSD op 24-11-2008 10:32 ]

[Flipke84]

Als je nu eens wat meer informatie geeft die gevraagd wordt dan kunnen we je ook helpen.

[leuk_he]

je .profile (enzo) wordt niet get als crontab/at job. verder is draaien als root niet zo'n goed idee.

een script aanroepen in de crontab als

su - batchuser -c "/home/users/batchuser/phpzooi"

lost wel wat problemen op waarschijnlij,

[RSD]

Jah ik maak gebruik van includes en de paden hiervan zijn ook absoluut. Net zoals in mijn andere cronjobs die het wel op een correcte manier doen.

[Creepy]

Voer dat ding nou eerst eens uit via cron zonder "> /dev/null 2>&1" zodat je output niet wordt weggegooid. Dan weet je zeer waarschijnlijk meer. Als je niet met meer informatie komt blijven wij ook maar gissen

[MueR]

Dan moet je gaan debuggen. Zet error_reporting(E_ALL) eens in je cron en zorg dat je wat nuttigs hier meld. Met 'het werkt niet' kunnen we niks. Mn glazen bol is momenteel in gebruik als schudbal voor de sneeuw buiten.

[Cartman!]

Heel andere oplossing (eigenlijk meer een workaround) die ik zelf wel eens gebruik: roep met je cronscript een url aan die die handeling uitvoert zodat het toch via je webserver gaat. Je script zelf zit dan dus niet in je cronjob scriptje. Kan erg handig zijn als je relatieve paden gebruikt bijvoorbeeld. Wel even beveiligen met een wachtwoordje oid.

[RSD]

Ik heb error_reporting(E_ALL) aangezet en de output naar /tmp/cron.log verwezen ... deze is inmiddels 12mb groot en staat vol met meldingen als:

Notice: Undefined variable: ok in
Notice: Undefined index: port in

en zo nog veel meer. Het zijn allemaal notices. Ik kom geen enkele error tegen. Ik gebruik wel een xml parse script. Maar deze doet het via het aanroepen van de prompt ook goed.

[RSD]

Als ik error_reporting(E_ALL) aanzet dan begint hij wel met het updaten van de database en als ik hem uit zet dan begint hij er niet mee. Dit weet ik doordat ik een check in de php file heb gemaakt, die OK of NOT OK uitvoert. Als ik de cron laat lopen zegt hij in het ene geval OK en in het andere geval NOT OK. Hier zit toch geen verschil in?

[MueR]

En nu ga je dus leren debuggen. Ga een aantal breakpoints in je code zetten en kijk waar de "normale" werking stopt. En dan ga je kijken hoe je dat op kan lossen. En dan doe je het nog een keer, net zo lang tot het werkt. Dat wil dus ook zeggen dat je niet elke scheet hier hoeft te posten, want dit wordt een erg langdradig topic waarin helemaal niks zinnigs gezegd wordt en jij nog steeds geen bruikbare informatie geeft over je probleem. Tot er iets zinnigs hier staat waar ik je mee kan helpen, ben ik klaar met dit topic.

[Fugitive1977]

Ik had een soort gelijk probleem, door de output via > /tmp/mijn.log te redirecten kwam ik erachter dat het aanroepen vanuit de cron, php deed starten in een zogenaamde "safe-mode", daardoor had ik ineens een probleem met de "max_execution time limit" oid.
Ik heb zo'n beetje alle ini files naagelopen maar geen van de instellingen leek enige invloed te hebben.
Gelukkig heb ik het probleem wel eenvoudig kunnen oplossen door het script via wget aan te roepen, waardoor PHP draait alsof het vanuit een browser wordt aageroepen.
wget heb ik zowel voor *nix en windows systemen, met in bovenstaand voorbeeld betrof het linux, waarop wget gelukkig standaard geinstalleerd was.
ipv /usr/local/bin/php /home/sites/domein.nl/import.php > /dev/null 2>&1
zul je zoiets moeten toevoegen aan je cron:
wget http://www.domein.nl/import.php -O /tmp/import.log
let op bij sommige wget versies is -o vereist om de output op te kunnen slaan, en bij andere -O, maar een simpele whet --help zal je daarover meer kunnen berichten.

Wellicht niet de "beste" of "mooiste" oplossing, maar voor mij een werkende oplossing, zonder een hoop aanpassingen.

[RSD]

Ik had eerst wget, maar dat gaf destijds problemen met de timeout of het memory gebruik. Raar, maar waar. Ik heb toen besloten om dit niet te doen.

Ik denk dat het probleem niet bij mij ligt, maar bij de urls die ik aanroep. De ene keer gaat het wel goed en de andere keer weer niet. Ik roep het script nu niet 1x per dag aan, maar 4x per dag. Allicht dat hij hem dan vast wel een keer goed doet.

[Verwijderd]

U heeft een enter staan aan het einde van de laatste regel in je crontab?

*zucht, eerst goed lezen darth, dan posten

RSD schreef op maandag 24 november 2008 @ 14:53:
[...]

Ik denk dat het probleem niet bij mij ligt, maar bij de urls die ik aanroep. De ene keer gaat het wel goed en de andere keer weer niet. Ik roep het script nu niet 1x per dag aan, maar 4x per dag. Allicht dat hij hem dan vast wel een keer goed doet.

Ik hoop dat je snapt dat dat natuurlijk geen solide en fatsoenlijke oplossing is. Lees de posts van MueR nog 's goed. Voeg desnoods een functie toe die regeltjes logt naar een logbestand en log na elke handeling wat er is gebeurt.

code:

* d/m/Y H:i:s bestand x opgehaalt van http:// (xx bytes)
* d/m/Y H:i:s connectie naar db ok
* d/m/Y H:i:s xx records geimporteerd
* d/m/Y H:i:s einde.

Lijkt misschien veel werk om in eerste instantie toe te voegen, maar het is erg prettig om als het ooit stuk gaat, of zoals nu, niet helemaal goed gaat, te weten wat er gebeurt. Desnoods log je ook alle functie calls. Het kan je een hoop duidelijk verschaffen in wat er nu eigenlijk gebeurt.
Standaard debug werk, tja, kan heel vervelend zijn, maar mits je genoeg info hebt, hoeft fixen van het probleem niet veel werk te zijn.

[ Voor 89% gewijzigd door Verwijderd op 24-11-2008 15:35 ]

[Fugitive1977]

ipv wget kun je ook eens naar curl kijken, volgens mij is de functionaliteit in dit geval bijna gelijk aan wget . . .