Crontab erst nach manuellem Daemon-Neustart

N

nighT

Hallo Leute,
ich hoffe erst mal, dass ich hier im richtigen Bereich bin. Da ich aber annehme, dass mein Problem durch mein Script ausgelöst wird, denke ich das schon.

Folgende Situation:
Ich habe ein Skript, welches per Crontab des Benutzers "manuel" alle Minute ausgeführt wird. Die Crontab dieses Users sieht folgendermaßen aus:
Code:
[manuel@blackbox ~]$ crontab -l
PATH=$PATH:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/vendor:/usr/lib/perl5/core_perl/bin

* * * * * /home/manuel/.startconky > /dev/null 2>&1 # JOB_ID_2
Das Skript:
Code:
[manuel@blackbox ~]$ cat ~/.startconky 
#!/bin/bash
getconky=`ps ax | grep conky | grep -v grep | grep -v startconky`
if [ "$getconky" == "" ]; then
sudo -u manuel notify-send -t 3000 "Conky not running at the moment.
Starting it now!"
sudo -u manuel conky --config=/home/manuel/.conkyrc
fi
Das Problem ist nun, dass nach dem start des PCs die Crontab nicht ausgeführt wird. Erst, wenn ich als root den Daemon (/etc/rc.d/crond restart) neustarte, wird das Skript richtig gestartet. Das Skript per Hand ausgeführt funktioniert auch wunderbar.
Die Rechte habe ich zu Testzwecken auch auf 777 gesetzt:
Code:
[manuel@blackbox ~]$ ls -la
...
-rwxrwxrwx  1 manuel manuel    251  3. Aug 22:36 .startconky
...
An was kann es noch liegen, dass das Skript erst nach dem Neustart von crond gestartet wird?

Infos zum System:
Distribution: ArchLinux
Cron-Version: 4.4-2

Sonstige Infos sind hoffentlich alle vorhanden.

Mit freundlichen Grüßen,
Manuel (nighT)
 
Zuletzt bearbeitet von einem Moderator:
Cron verschickt auftretende Fehler im Normalfall via Email an den entsprechenden User. Du könntest also einfach mal einen lokalen MTA installieren und schauen, ob dein User irgendwelche Fehlermeldungen zugeschickt bekommt. Ansonsten könnte ein Blick in die System-Logs Aufschluss darüber geben, was dort schief läuft. Startet denn der Cron-Daemon beim Booten überhaupt und wird z.B. die globale Crontab ausgeführt? Anders gefragt: Betrifft das nur die User-Crontab?
 
Cron verschickt auftretende Fehler im Normalfall via Email an den entsprechenden User.
Mails kommen keine an. Laut den Logs ist das auch kein "Fehler". Warum das Skript nicht startet, verstehe ich aber dennoch nicht..

Ansonsten könnte ein Blick in die System-Logs Aufschluss darüber geben, was dort schief läuft.
Folgende Ausgabe wiederholt sich minütlich (Skript wird minütlich ausgeführt):
Code:
[root@blackbox manuel]# cat /var/log/crond.log 
Aug  4 17:24:02 blackbox crond[1619]: /usr/sbin/crond 4.4 dillon's cron daemon, started with loglevel info
Aug  4 17:25:01 blackbox crond[1619]: FILE /var/spool/cron/manuel USER manuel PID 2072 /home/manuel/.startconky > /dev/null 2>&1 # JOB_ID_2
Aug  4 17:25:02 blackbox crond[1619]: exit status 1 from user manuel /home/manuel/.startconky > /dev/null 2>&1 # JOB_ID_2
Das ist auch die einzige Ausgabe, nachdem ich die Log geleert und den PC neugestartet hatte.

Startet denn der Cron-Daemon beim Booten überhaupt
Ja, der Cron-Daemon startet beim booten. Per "ps ax" finde ich den gestarteten Daemon ebenfalls.

wird z.B. die globale Crontab ausgeführt? Anders gefragt: Betrifft das nur die User-Crontab?
Habe das ganze mal mit einem kleinen Skript getestet, welches durch die root-crontab und die user-crontab ausgeführt wird und den jeweiligen ausführenden Benutzer in eine log-Datei schreibt. Das Ergebnis:
Code:
[17:38:01] Skript durch >>root<< ausgeführt
[17:38:01] Skript durch >>manuel<< ausgeführt
[17:39:01] Skript durch >>root<< ausgeführt
[17:39:01] Skript durch >>manuel<< ausgeführt
[17:40:01] Skript durch >>root<< ausgeführt
[17:40:01] Skript durch >>manuel<< ausgeführt
Dieses Skript wird also problemlos ausgeführt. Der Fehler scheint also irgendwo in meinem eigenen Skript zu sein. Allerdings verstehe ich dann nicht, was ein Neustart des Cron-Daemons damit zu tun hat....
 
Nimm mal bitte zum Testen die Umleitung des Outputs nach /dev/null raus und schau ob es dann immernoch keine Fehlermeldungen gibt.
 
Da dein Test-Skript ja scheinbar ausgeführt wurde, kannst du davon ausgehen, dass Cron selbst korrekt funktioniert. Der Fehler ist also eher im Skript oder in der für das Skript gesetzten Umgebung zu suchen. Sind alle Befehle, die das Skript verwendet innerhalb des gesetzten $PATH zu finden? Wird ein simples 'echo' am Anfang des Skripts korrekt ausgeführt, wenn du es dort einfügst?
 
Ich habe nun mal explizit die PATH-Variable und die SHELL-Variable in der Crontab gesetzt, mit folgendem Fehler in der /var/log/crond.log:
Code:
Aug  4 18:18:14 blackbox crond[1598]: failed parsing crontab for user manuel: SHELL=/bin/bash
Aug  4 18:18:14 blackbox crond[1598]: failed parsing crontab for user manuel: PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/vendor:/usr/lib/perl5/core_perl/bin
Wie kommt der Fehler zustand? Die Path-Angaben habe ich per "echo $PATH" mit dem ausführenden User genommen...
 
Stehen die Umgebungsvariablen ganz am Anfang der Crontab?
 
Jap. Ganz oben. Nur die SHELL Variable kommt davor, wobei das ja eigentlich kein Problem darstellen dürfte...
 
Dieses Verhalten ist wirklich seltsam. Ich bin da momentan etwas ratlos. Ggf. hilft es, wenn du im Skript alle Pfade absolut machst (sollte man bei Cron-Skripten eh tun um unabhängig vom Environment zu sein). Man muss halt bedenken, dass das Skript nicht im gleichen Kontext läuft wie bei einer zuvor aufgerufenen Shell, die zumeist eine "Login-Shell" ist. Ausserdem kannst du ja mal verschiedene Exit-Codes einbauen um zu sehen ob z.B. die eingebaute Bedingung nicht greift. Der Exit-Code wird ja offenbar korrekt geloggt. Also gibst du einfach mal in der Bedingung Exit-Code 1 zurück und ausserhalb Exit-Code 2.
 
Absolute Pfade habe ich, nachdem ich auch mal auf die Idee mit der PATH-Variable kam, gesetzt. Das hilft ebenfalls nicht. Egal, ob mit oder ohne gesetzter PATH-Variable.

Das mit den Exit-Codes werde ich mir morgen mal anschauen. Der Notebook, auf dem die ganze Sache läuft oder laufen soll ist gerade aus und ich bin zu faul, ihn anzumachen.

Falls ich damit auch kein brauchbares Ergebnis zustande bringe, werde ich das Script mal nach /etc/cron.hourly verfrachten. Dort müssten die Environment-Variablen ja korrekt gesetzt sein. Wenn das Script dann dort immer noch nicht funktioniert, scheint es an irgend einem Teil des Scriptes zu liegen. Wobei sich dann schon wieder die nächste Frage stellt: An welchem Teil? Ich verwende außer grep, und ps doch nichts.
Oder kann es sein, dass es dem User aus irgend welchen Gründen nicht gestattet ist, aus einem Cron-Script andere Scripte anzustoßen? Werde morgen noch ein echo in eine Datei einbauen...

Schonmal Danke für deine Hilfe. Hoffentlich wird einer der Tests zu einem brauchbaren Ergebnis führen.

Grüße Manuel
 
Nunja, du verwendest ja auch noch conky, notify-send und sudo.
 
Das stimmt schon. Wobei Ich sudo nun rausgenommen habe (Es handelt sich ja sowieso um die User-Crontab. Root hat da ja nix mehr zu machen) und conky+notify-send sind zumindest in einer normalen User-Shell zu erreichen. Die Programme liegen jeweils in einem Pfad aus PATH, sind zum Test aber auch als absolute Pfade angegeben
 
Zuletzt bearbeitet von einem Moderator:
Habe mich nun doch noch dazu entschlossen, den Notebook zu starten.
Ich bin nun so weit, dass ich weiß, dass das Script ausgeführt wird. Die echo's werden ebenfalls ausgegeben. conky und notify-send werden also tatsächlich nicht ausgeführt... Beide Dateien unter /usr/bin haben aber testweiße ein "chmod 777" abbekommen.
Hier nochmal mein Script im aktuellen Zustand:
Code:
#!/bin/bash
getconky=`/bin/ps ax | /bin/grep conky | /bin/grep -v grep | /bin/grep -v startconky`
if [ "$getconky" == "" ]; then

/usr/bin/notify-send -t 3000 "Conky not running at the moment.
Starting it now!"
echo "notify-send" >> /home/manuel/Desktop/conkylog.log

/usr/bin/conky --config=/home/manuel/.conkyrc
echo "conky gestartet" >> /home/manuel/Desktop/conkylog.log
fi
 
Lass dir mal $getconky ausgeben bevor die Bedingung betreten wird. Ich tippe nämlich drauf, dass die Bedingung nicht matcht, weil z.B. das 'grep' doch noch auftaucht o.ä..
 
Das kann nicht sein, da ich innerhalb der Bedingung ja die echo's in eine Datei ausgebe. Diese echo's kommen auch an. Also kann es eigentlich nur direkt an dem Starten von Conky bzw. libnotify liegen... Aber ich verstehe einfach nicht warum das erst nach einem Neustart des Daemons funktioniert..
 
Morgen,

um "send-notify" in einem Cronjob zu verwenden musste ich damals noch ein
Code:
 export DISPLAY=:0.0
in das Skript einbauen.

Alle Tests auf der shell Funktionierten tadellos, nur über den Cron lief es nicht.

mfg
HeadCrash
 
Morgen,

um "send-notify" in einem Cronjob zu verwenden musste ich damals noch ein
Code:
 export DISPLAY=:0.0
in das Skript einbauen.

Alle Tests auf der shell Funktionierten tadellos, nur über den Cron lief es nicht.

mfg
HeadCrash
Vielen Dank für deinen Tipp! Manchmal kann die Lösung so einfach sein...
Wundert mich nur, dass es dann nach dem Neustart des Daemons funktioniert. Ist die DISPLAY-Variable vielleicht noch nicht gesetzt, wenn crond gestartet wird?
 
Im Zweifelsfall mal beim booten ein "env" wegschreiben lassen und eins nach dem neustart.
 

Ähnliche Themen

Shellskript - Fehler in Cron

Postfix issue

sed im script per crontab

HP PSC 2175 - CUPS druckt nicht

Kein WM startet mit Benutzer/root, außer Xfce !

Zurück
Oben