Bekijk de volledige versie : Crontab wird nicht ausgeführt....
Hallo,
ich habe folgende Zeile in der Crontab stehen:
42 08 * * * admin "/opt/sbin/logrotate /opt/etc/logrotate.conf"
Ursprünglich stand dort mal 00 00 * * * für Täglich um 0 Uhr... habe gerade
mal zum testen die Aktuelle Uhrzeit genommen....
Allerdings wird der Befehl nicht ausgeführt... Der Crondienst läuft und
in der cron.allow steht der User admin auch drin.
Im syslog finde ich nur den Hinweis auf Bearbeitung, aber keine Fehler....
Dec 15 08:35:01 /opt/sbin/cron[727]: (admin) RELOAD (crontabs/admin)
Dec 15 08:40:38 crontab[1318]: (admin) BEGIN EDIT (admin)
Dec 15 08:41:03 crontab[1318]: (admin) REPLACE (admin)
Dec 15 08:41:03 crontab[1318]: (admin) END EDIT (admin)
Dec 15 08:42:01 /opt/sbin/cron[727]: (admin) RELOAD (crontabs/admin)
Kann mir jemand einen Tipp geben?
(Startscript und rooter nach Wendi´s Howto....)
Stimmen die Rechte für crontab? Ich bin erst neulich selber drauf reingefallen, siehe hier: http://www.wl500g.info/showthread.php?t=17375. Ich glaube, es steht auch nicht explizit in Wengis HowTo, kann mich aber irren.
Gruß
Robert
danke für den Tipp... aber die Rechte stimmen... ein anders Script wird auch ausgeführt...
habe den Fehler gefunden....
erstens gibt es Probleme wenn ich den Benutzer mit angebe unter dem das Script laufen soll...
ein
* * * * * admin date >> /tmp/date.txt
bringt folgenden Meldung im Syslog:
Dec 15 10:57:01 /opt/sbin/cron[1856]: (admin) CMD (admin date >> /tmp/date.txt)
In der datei date.txt steht dann nichts drin....
ein
* * * * * date >> /tmp/date.txt
geht problemlos....
zweitens sind die Anführungszeichen nicht nötig und behindern sogar die
Ausführung....
Diese Zeile funktioniert nun ohne Probleme
50 10 * * * /opt/sbin/logrotate /opt/etc/logrotate.conf
SirAuron
20-05-2010, 12:08
Hallo zusammen,
ich versuche seit gestern ein DynDNS-Skript über einen Cronjob laufen zu lassen. Leider wird dieses jedoch nicht ausgeführt.
In /opt/etc/crontab steht folgendes drin:
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/sbin:/opt/bin
MAILTO=""
HOME=/
# ---------- ---------- Default is Empty ---------- ---------- #
0 0 * * * admin /opt/sbin/logrotate -f /opt/etc/logrotate.conf &>/dev/null
* * * * * admin /tmp/harddisk/dyndns/regfish_ipcheck2.sh
Die crontab ist mit den Rechten 600 versehen und am Ende der cronta ist eine Leerzeile mit Enter eingefügt.
In /opt/var/log/syslog.log erscheint dann auch minütlich:
May 20 13:05:01 /opt/sbin/cron[260]: (admin) CMD (/tmp/harddisk/dyndns/regfish_ipcheck2.sh)
Allerdings wird das Shellskript nicht ausgeführt. Wenn ich es manuell über die Shell ausführe, funktioniert alles. Die Rechte für das Skript sind auf 744 gesetzt.
Kann mir jemand sagen, was ich falsch mache?
hast du ein "chmod +x /tmp/harddisk/dyndns/regfish_ipcheck2.sh" ausgeführt? (script ausfürbar machen)
p.s. der output der scripte/programme die über cron ausgeführt werden, wird an den user gemailt (falls mailto: gesetzt ist.) oder geht verloren. wenn du den output irgenwohin schreiben willst, musst du in der crontab ">> targetfile" an das commando anhängen, oder im script diese ausgaben selber in die gewünschten files schreiben.
(falls du das script für eine dyndns-aktualisierung brauchts, kannst du dir auch mal inadyn anschauen, das gibt über ipkg und dyndns kann dafür config-files produzieren)
SirAuron
20-05-2010, 13:11
Danke für deine Ratschläge. Ich habe die Datei nochmal mit chmod bearbeitet, auch wenn die Rechte eigentlich schon vergeben waren.
Leider bringt weder dies, noch der Tipp mit dem Weiterleiten der Ausgabe den gewünschten Erfolg.
Hat jemand noch eine andere Idee?
Also laut Cron-Syslog-Eintrag wird dein Script ausgeführt. Wie sieht das Script aus? Ausführbar ist es, hast du ja überprüft. Ist es eventuell was ganz blödes, wie #!/bin/bash in der ersten Zeile fehlt, oder was weiß ich... Kannst du in das Script ein 'echo' einbauen, das etwas ins Syslog schreibt oder einen Befehl, der eine Dummy-Datei unter /tmp anlegt, oder noch etwas, so dass du sicher sein kannst, dass das Script ausgeführt wurde?
Gruß
Robert
SirAuron
21-05-2010, 21:20
Hab das Problem jetzt endlich gefunden. Das Problem lag definitiv im Shellskript. Das Problem war, dass im Skript ein wget-Aufruf vorkommt, aber die Umgebungsvariablen zwischen dem Cronjob und der Usershell unterschiedlich sind. D.h. das Skript funktioniert manuell vom User ausgehend, aber nicht über den Cron-Service. Absolute Pfadangabe für wget hat die Lösung gebracht.