Leerzeile am Ende:
Das sollte eigentlich beim Busybox-crond keine Rolle spielen. Der liest mit "libbb/parse_config.c -> config_read()" aus der crontab, was nach einigen Schritten dann beim "getline" der µClibc landet und das arbeitet auch korrekt, wenn die letzte Zeile im Stream nicht mit einem Newline endet. Die Aussage im Wiki gilt eher für den bei Ubuntu normalerweise verwendeten Daemon, nicht für die Busybox ... einfach mal ausprobieren.
Und das "env sh" sollte man auch gleich durch ein "sh" ersetzen können (dann geht die Suche eben wieder über die PATH-Variable), wenn man nicht noch irgendwelche Sachen im Environment parallel verändern will:
Code:
if (argv[0]) {
BB_EXECVP_or_die(argv);
}
(aus Busybox 1.23.2, coreutils/env.c)
Es wird - nach Verarbeitung der hier ja nicht genutzten Optionen - ganz simpel der Rest der Zeile an "execvp" übergeben, der "Umweg" über "env" bringt also im Endeffekt tatsächlich nichts als einen weiteren (unnötigen) Programmaufruf. Die Suche läuft genauso ab, wie ohne "env" ...
Embedded ist eben immer noch ein klein wenig anders, als "normales" Linux ... macht nicht in jedem Falle einen entscheidenden Unterschied, kann aber auch mal zur Falle werden, weil bei Embedded-Systems eben gerne mal - wie bei AVM auch - alles in einem privilegierten Kontext läuft und schon kleine Fehler die Sicherheit komplett in die Tonne treten können.
Sorry für den Zeigefinger ... wollte den Unterschied "Linux <-> Embedded Linux" (in erster Linie allerdings bei den eingesetzten Tools auf "kleinen" Systemen) einfach noch einmal loswerden oder betonen.
@phreichmuth:
Der crond startet ja nach den Angaben auf Deiner Console den Job, sogar die PID des gestarteten Jobs ist vorhanden, da wird also tatsächlich etwas geforkt und das Protokollieren erfolgt erst danach.
Bis dahin ist also alles erst einmal in Ordnung mit Deiner crontab und eine Suche davor macht nur bedingt Sinn.
Das Problem muß demnach irgendwo im Start des Skripts aus dem crond heraus liegen, da besteht offenbar ein Unterschied zu Deiner Shell-Session.
Wenn Du den Hinweis zur PATH-Variablen umgesetzt hast und es immer noch nicht funktioniert, wäre vielleicht mal das auszuführende Skript eine echte Hilfe beim Erraten der Ursache ... den Hinweis zum Debuggen mit "-x" hast Du ja vielleicht nur überlesen oder nicht verstanden, ansonsten müßtest Du ja irgendeine Ausgabe erhalten haben, die Du mit uns teilen könntest.
Letzter Hinweis: Wenn Du die MAILTO-Variable nicht brauchst, kannst Du sie problemlos auch weglassen, dann läuft man keine Gefahr, sich mit dem leeren Parameter Probleme einzuhandeln (s. Busybox, miscutils/crond.c). Das gilt für die Standard-Einstellungen (SHELL und HOME) genauso ... ist alles Ballast, den es eigentlich nicht braucht. Wenn Du nicht tatsächlich irgendwelche zusätzlichen ausführbaren Files in /var/tmp (/tmp/var ist ja wahrscheinlich fehlerhaft) suchen lassen willst (gefährlich, da darf jeder schreiben ... aber bei Dir wird ja wenigstens - richtigerweise - erst dann dort gesucht, wenn vorher nichts gefunden wird), dann kannst Du die PATH-Angabe auch noch weglassen. Es ist - bis auf /tmp/var - nichts Falsches daran, aber zur Fehlersuche würde ich mögliche Quellen eben minimieren.
Die Bemerkung zur PATH-Variablen würde ich auch gerne noch etwas ergänzen: Es gibt bei der Busybox eine Option (CONFIG_FEATURE_PREFER_APPLETS), mit der zur Build-Time die Suchreihenfolge geändert werden kann ... deshalb sollte man als Verwender einer fremden Busybox schon wissen, wie diese generiert wurde. Wenn dieses Feature aktiviert ist, wird immer als erstes die Liste der in der Busybox enthaltenen Applets durchsucht. Damit ist es dann eben auch möglich, sagen wir mal das "rpm"-Applet aufzurufen, auch wenn für dieses kein Link auf das Busybox-Binary im Suchpfad existiert. Ist diese Option nicht gesetzt, wird der Pfad sofort durchsucht. An dieser Stelle kommt dann die Warnung vor ungültigen Annahmen ins Spiel ... wenn der Pfad - wie bei Dir - Verzeichnisse enthält, wo praktisch jeder Schreibzugriff hat und man Kommandos aufruft, deren Pfad nicht absolut angegeben ist bzw. man sich auf die Suche durch das System verläßt, dann würde eben bei einer Busybox mit CONFIG_FEATURE_PREFER_APPLETS=n eine ausführbare Datei in /var/tmp eher gefunden und aufgerufen, als ein in der Busybox enthaltenes Applet. Das muß nicht, kann aber, zu einem Einfallstor für einen Angreifer werden ... nach /var/tmp wird praktisch alles geschrieben. Das mit einem Aufruf von "tar" durch die Firmware verbunden (es gibt einige davon in der AVM-Firmware) und man kann mit hoher Wahrscheinlichkeit problemlos eine Datei in /var/tmp erzeugen, die dann auch noch "executable" ist - von der Möglichkeit des "normalen" Schreibens mit passender umask ganz zu schweigen. Wenn dieses Verzeichnis hingegen nicht im Pfad ist, vermeidet man zumindest die Probleme, die sich aus impliziten Aufrufen (also ohne absoluten Pfad zum Kommando) ergeben könnten. Wenn man unbedingt zur Laufzeit in einer FRITZ!Box ein beschreibbares Verzeichnis benötigt, das bei der Suche nach ausführbaren Dateien einbezogen wird, dann legt man sich ein solches gesondert an (meinetwegen /var/scripts oder /var/exec) und benutzt nicht das TMP-Verzeichnis.
