Ein Cronjob, der nie läuft

Der Befehl läuft in Ihrem Terminal und liefert um drei Uhr morgens nichts. Cron ist nicht kaputt. Es führt Ihren Befehl in einer Umgebung aus, die Ihrer Shell fast in nichts gleicht — und dieser Unterschied ist die ganze Antwort.

Sehen Sie nach, was passiert ist

grep CRON /var/log/syslog | tail -20

Steht Ihr Job dort gar nicht, hat cron es nie versucht. Steht er dort, hat cron ihn ausgeführt und etwas anderes ist schiefgegangen.

1. PATH ist fast leer

Ihre Shell weiß, wo php liegt. Cron nicht — sein PATH ist meist nur /usr/bin:/bin. Benutzen Sie immer den vollen Pfad.

which php
# /usr/bin/php8.3

# in the crontab
0 3 * * * /usr/bin/php8.3 /var/www/site/cron.php

2. Die Ausgabe geht ins Leere

Ein Job ohne Umleitung schickt seine Ausgabe an eine Mail, die nicht eingerichtet ist — also verschwinden Fehler. Schicken Sie sie in eine Datei, und der nächste Fehlschlag erklärt sich selbst.

0 3 * * * /usr/bin/php8.3 /var/www/site/cron.php >> /var/log/site-cron.log 2>&1

3. Der falsche Benutzer

Ein Job in roots crontab schreibt Dateien, die root gehören und die der Webserver dann nicht ändern kann. Legen Sie ihn in die crontab des Benutzers, dem die Website gehört.

crontab -u youruser -l

4. Ein Prozentzeichen

Testen Sie ihn so, wie cron es tun wird

env -i /bin/sh -c "/usr/bin/php8.3 /var/www/site/cron.php"

Das führt ihn mit leerer Umgebung aus — genau das tut cron. Scheitert er hier, scheitert er auch um drei.