Crontab erst nach manuellem Daemon-Neustart

Dieses Thema im Forum "Shell-Skripte" wurde erstellt von nighT, 04.08.2010.

  1. #1 nighT, 04.08.2010
    Zuletzt von einem Moderator bearbeitet: 04.08.2010
    nighT

    nighT Guest

    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)
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. #2 bitmuncher, 04.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    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?
     
  4. nighT

    nighT Guest

    Mails kommen keine an. Laut den Logs ist das auch kein "Fehler". Warum das Skript nicht startet, verstehe ich aber dennoch nicht..

    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.

    Ja, der Cron-Daemon startet beim booten. Per "ps ax" finde ich den gestarteten Daemon ebenfalls.

    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....
     
  5. #4 bitmuncher, 04.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    Nimm mal bitte zum Testen die Umleitung des Outputs nach /dev/null raus und schau ob es dann immernoch keine Fehlermeldungen gibt.
     
  6. nighT

    nighT Guest

    Die Ausgabe sieht noch genau so mager aus...
     
  7. #6 bitmuncher, 04.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    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?
     
  8. nighT

    nighT Guest

    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...
     
  9. #8 bitmuncher, 04.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    Stehen die Umgebungsvariablen ganz am Anfang der Crontab?
     
  10. nighT

    nighT Guest

    Jap. Ganz oben. Nur die SHELL Variable kommt davor, wobei das ja eigentlich kein Problem darstellen dürfte...
     
  11. #10 bitmuncher, 05.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    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.
     
  12. nighT

    nighT Guest

    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
     
  13. #12 bitmuncher, 05.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    Nunja, du verwendest ja auch noch conky, notify-send und sudo.
     
  14. #13 nighT, 06.08.2010
    Zuletzt von einem Moderator bearbeitet: 06.08.2010
    nighT

    nighT Guest

    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
     
  15. Anzeige

    Vielleicht findest du HIER Antworten.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  16. nighT

    nighT Guest

    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
    
     
  17. #15 bitmuncher, 06.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    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.ä..
     
Thema:

Crontab erst nach manuellem Daemon-Neustart

Die Seite wird geladen...

Crontab erst nach manuellem Daemon-Neustart - Ähnliche Themen

  1. Verständnissfrage crontab

    Verständnissfrage crontab: Morgähn... Nur ne kleine Verständnissfrage am frühen Morgen... in manchen Artikeln zu cron wird das so angegeben: minuten stunde tag monat...
  2. centos crontab reboot zeit

    centos crontab reboot zeit: Hi jungs habe wieder mal ne frage ich möchte mein centos rechner jeden tag um 05 uhr rebooten und habe vollgendes in /etc/crontab eingetragen 00...
  3. Cygwin - Crontab

    Cygwin - Crontab: Hallo Leute, ich bin neu in der Linux Welt. Bzw. ich taste mich Schritt für Schritt ran *g Vorgeschichte: Ich habe eine Domäne (Windows)....
  4. crontab

    crontab: Hallo, irgendwas verstehe ich heute nicht... #echo $UID 0 #set . . . Holz=333 Kohle=444 . . . #cat /usr/local/sbin/skript1...
  5. sed im script per crontab

    sed im script per crontab: hallo und nen schönen Tag wünsche ich, Ich bin dabei ein script zu schreiben das mir die daten in eine log-datei schreibt. Das klappt auch soweit...