Warum Cronjobs auf Shared Hosting regelmäßig zicken
Kaum ein Cronjob läuft auf Shared Hosting direkt durch. Irgendwas ist immer: Zeitzone daneben, Pfad falsch, Interpreter nicht gefunden. Kein Hexenwerk, aber die Klassiker tauchen in jedem zweiten Support-Thread wieder auf.
Hier die üblichen Verdächtigen – und was dagegen hilft, ohne stundenlang zu fluchen.
Zeitplanung: Zeitzonen-Murks und Syntax-Chaos
Zeitzonen: Dauerbrenner. Viele Provider fahren ihre Server auf UTC. Erwartet wird aber meist MEZ oder MESZ – schon startet der 3-Uhr-Job nicht um drei, sondern irgendwann. Wer nicht aufpasst, wundert sich über leere Backups zu merkwürdigen Zeiten.
Cron-Syntax: Ein fehlendes Feld, ein verpeiltes Komma, und schon läuft der Job nie oder dauernd. Klassiker: "* * * *" – und dann wundern, warum das Skript die CPU grillt.
Immer wieder gesehen:
- Server-Zeitzone nicht geprüft, stattdessen blind auf lokale Zeit verlassen
- Cron-String einfach getippt, nie getestet
- Sonderzeichen, die weder Cron noch der Hoster schlucken
Was hilft?
- Zeitzone vorher prüfen (SSH: "date" oder im Panel suchen)
- Cron-Ausdruck im Online-Validator testen
- Am Anfang lieber schlichte Zeiten – keine wilden Muster
Pfadangaben: Skript sucht sich zu Tode
Cron startet in Minimal-Umgebung. Relativer Pfad? Funktioniert meist nicht. Skript findet sich selbst nicht, Ressourcen fehlen, PHP liegt irgendwo im Nirgendwo.
Häufige Fehler:
- Skripte mit "./" oder ohne Pfadangabe aufrufen
- "php" ohne vollen Pfad
- PATH-Variable fehlt komplett, Befehl unbekannt
Lösung?
- Absolute Pfade für alles: Interpreter, Skript, Logs
- "which php" im Terminal, dann kopieren (nicht raten)
- Debug-Skript bauen, das in eigene Logdatei schreibt – sieht man wenigstens, was passiert
Multi-PHP ist auch gern ein Problem. "php" zeigt auf PHP 7.4, im Web läuft aber 8.3. Merkt man spätestens, wenn das Skript mit "unknown function" abschmiert. Nachfragen beim Support schadet nie, manchmal ist der Pfad zur richtigen CLI-Version tief im Wiki versteckt.
PHP-CLI und Web-PHP: Nicht dasselbe
Viele glauben, "php" ist "php". Falsch. Im Cron läuft oft ein anderes PHP als im Browser. Manchmal erwischt das System "php-cgi" statt "php-cli" – und schon funktioniert nix, weil Umgebungsvariablen oder Extensions fehlen.
Typische Fehler:
- Falscher Interpreter im Cronjob (php-cgi statt php-CLI)
- CLI mit zu wenig Extensions
- Annahme: "php" im PATH ist schon das Richtige
Was bringt's?
- Den echten Pfad zur CLI rausfinden: "/usr/local/bin/php7.4" oder ähnlich
- Im Skript keine Web-Konstanten wie $_SERVER nutzen
- Fehler ins Log umleiten, sonst sieht man gar nichts
Weitere Fallen: Von Log bis Shell
- Log-Output nie vergessen: ">> /home/user/cron.log 2>&1" hinten dran. Sonst tappt man völlig im Dunkeln.
- Shell: Nicht jeder Hoster nimmt Bash. Manchmal läuft Dash oder etwas Exotisches. "#!/bin/bash" oben ins Skript schadet nicht.
- PHP-Fehlerausgabe: error_reporting(E_ALL); ini_set('display_errors', '1'); bringt Licht ins Dunkel – zumindest beim Testen.
- Hosting-FAQ lesen. Manche Provider sperren Cronjobs ab, haben Limits oder spezielle Eigenheiten. Steht meist irgendwo tief im Wiki oder in den AGBs, natürlich nie direkt auf der Produktseite.
Praxis: Der Backup-Cron macht nix – warum bloß?
Klassiker: Ein Backup-Skript soll nachts laufen. Log sagt: gestartet. Aber kein Backup da. Nachgesehen:
- Cron-Eintrag: 0 3 * * * php backup.php
- "php" ist aber nur ein Link auf php-cgi, das CLI fehlt. Skript startet – und bricht ab.
- backup.php arbeitet mit relativen Pfaden. Im Cron-Kontext findet er das Zielverzeichnis nicht.
Lösung – Schritt für Schritt:
- Mit "which php" den echten CLI-Interpreter gefunden: "/usr/local/bin/php"
- Cronjob angepasst: 0 3 * * * /usr/local/bin/php /home/user/scripts/backup.php >> /home/user/cron.log 2>&1
- Skript auf absolute Pfade umgebaut
Ergebnis: Backup läuft – und landet auch da, wo es hingehört.
Fazit: Weniger raten, mehr prüfen
Cronjobs auf Shared Hosting sind kein Mysterium. Aber sie verzeihen kaum Schlamperei. Zeitzone checken, absolute Pfade, expliziter PHP-Pfad. Log-Ausgabe immer aktivieren. Dann erledigt sich das meiste von selbst – und der Support bleibt ruhig.
Vor dem nächsten Cronjob:
- Zeitzone checken
- Überall absolute Pfade
- PHP-CLI exakt angeben
- Log-Ausgabe dranbauen
Mit diesen Basics bleibt das Cron-Log endlich lesbar – und das Skript macht, was es soll.
bye
mo
Anhänge
Zuletzt bearbeitet: