Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Vor einiger Zeit haben die Maintainer des fcron-Daemons aus Sicherheitsgründen eine Verschärfung eingeführt, die insbesondere die Umgebung (Environment), in der der cron-Job ausgeführt wird, betrifft. Wichtig ist hier meist die Einschränkung in der PATH-Variablen, die nun nicht mehr /sbin und /usr/sbin enthält. Benutzt man nun in seinem per cron auszuführenden Skript Kommandos, die sich in diesen Pfaden befinden, aber nicht mit vollem Pfad angegeben wurden, werden diese dadurch nicht mehr gefunden. Das kann sogar passieren, wenn man glaubt nur interne Befehle in einem php-Skript verwendet zu haben, z. B. die interne php-Funktion mail.

Man wird sich wundern, dass trotz Ausführung als cron-Job nie eine Mail kommt aber auf der Kommandozeile funktioniert es prima.Man kommt Problemen mit der Ausführung von cron-Jobs meist auf die Spur, wenn man dafür sorgt, dass das der cron von fcron auszuführende Programm einen Fehler an fcron (Errorlevel <> 0) zurückliefert, denn dann versendet fcron eine Fehlermail an root mit der kompletten Ausgabe des Skripts/Befehls/Programms). In Shell-Skripten schreibt man dazu am Ende ein "exit 1", in php-Skripten am Ende ein "exit(1);"; in allen Programmiersprachen gibt es eine analoge Möglichkeit hierzu.Nehmen wir nun also mal das Beispiel

Beispiel: Versenden einer Mail mittels eines php-Skriptes

...

per fcron-Job

Man wird sich wundern, dass trotz Ausführung als cron-Job nie eine Mail kommt, aber auf der Kommandozeile funktioniert es prima.

Wenn dieses Skript nun einen Fehler durch Setzen des Errorlevels auf einen Wert <> 0 an fcron meldet, erhält man vom fcron diesem eine Mail etwa folgenden Inhalts:

...