crontab / cron jobs

  • Vorweg:


    Für Individuelle Probleme oder Problemlösungen usw bitte einen eigenen Thread erstellen, aber euer Problem nicht in den Anleitungs-Threads behandeln, sonst werden diese sehr schnell sehr unübersichtlich und keiner hat mehr Lust sich Seitenweise eigentlich belangloses Zeug (nichts was mit der Anleitung zu tun hat) durchzulesen.
    Danke




    Der Cron-Daemon dient der zeitbasierten Ausführung von Prozessen in Unix und unixartigen Betriebssystemen wie Linux, BSD oder Mac OS X, um wiederkehrende Aufgaben – sogenannte Cronjobs – zu automatisieren.


    Die auszuführenden Anweisungen werden in einer benutzereigenen Tabelle gespeichert, der sogenannten Crontab. Der Begriff leitet sich ab von griechisch chronos = die Zeit und lat. tabula = die Tafel oder das Brett und bedeutet demnach so viel wie „Zeittafel“ (also „Stundenplan“).


    Diese Tabelle besteht aus sechs Spalten; die ersten fünf dienen der Zeitangabe (Minute, Stunde, Tag, Monat, Wochentag), alle weiteren Zeichen bis zum Zeilenumbruch werden als der auszuführende Befehl aufgefasst.


    Jedes Mal, wenn ein spezifischer Zeitpunkt erreicht wird, wird der entsprechende Befehl, meist ein Shellskript, ausgeführt.




    Es gibt 2 Arten von crontabs die es zu unterscheiden gilt:

    • Benutzer-Crontab -> Kann über den Konsolen Befehl crontab -e bearbeitet werden


    • System-Crontab -> Datei /etc/crontab
      gehört dem System und sollte von - egal welchen - Benutzern nicht geändert werden!


    Die System-Crontab hat eine Spalte mehr als die Benutzer-Crontab, nämlich mit dem Benutzer der den Befehl oder Script ausführen soll


    Wie auch bei Scripts üblich werden auch die crontabs von oben nach unten abgearbeitet, ist aber eine Zeile fehlerhaft wird alles dadrunter nicht mehr ausgeführt - also am besten eure eigenen Einträge ans Ende paken. Wichtig ist aber das ihr nach eurer Zeile <Enter> drückt also ein Zeilenumbruch habt!



    Standardmässig wird die Crontab mit vi geöffnet. Wer stattdessen lieber nano nutzen möchte gibt ein mal folgenden Befehl ein: export EDITOR=nano


    Ein Crontab-File besteht aus 6 "Spalten" pro Zeile:
    1 - Minute (0-59)
    2 - Stunde (0-23)
    3 - Tag des Monats (1-31)
    4 - Monat des Jahres (1-12)
    5 - Wochentag (0-7, Sonntag ist 0 und 7)
    6 - Absoluter Pfad zum Befehl/Script


    Zur Verdeutlichung:

    Code
    *     *     *     *     *  Befehl der ausgeführt werden soll
    -     -     -     -     -
    |     |     |     |     |
    |     |     |     |     +----- Wochentag (0 - 7) (Sonntag ist 0 und 7)
    |     |     |     +------- Monat (1 - 12)
    |     |     +--------- Tag (1 - 31)
    |     +----------- Stunde (0 - 23)
    +------------- Minute (0 - 59)



    Eine Ausnahme bildet allerdings wie bereits erwähnt die /etc/crontab Datei! Da gibt es eine Spalte mehr um anzugeben wer den Befehl oder das Script ausführen soll:
    1 - Minute (0-59)
    2 - Stunde (0-23)
    3 - Tag des Monats (1-31)
    4 - Monat des Jahres (1-12)
    5 - Tag der Woche (0-6, 0 ist Sonntag)
    6 - Auszuführender Benutzer
    7 - Absoluter Pfad zum Befehl/Script





    Benutzer-Crontab Beispiele: (crontab -e)



    System-Crontab Beispiele: (/etc/crontab)



    Es gibt auch noch weitere Crontab-untypische Einstellungsmöglichkeiten wie @reboot
    Genaueres dazu kann man dort nachlesen: http://wiki.ubuntuusers.de/Cron#Cronjobs-manuell-einrichten
    (etwas runter scrollen bis zur Tabelle "String, Bedeutung, cron-Schreibweise")



    Wichtig ist auch das ihr nicht Systemdateien überschreibt! Also nicht daher gehen und /etc/crontab oder /etc/rc.local usw mit unter Windows bearbeiteten Dateien überschreiben! Dabei gehen Dateirechte usw verloren!






    Anmerkungen:


    Unter Raspbmc wird der Cron Dienst standardmässig leider nicht automatisch ausgeführt!
    Dafür gibt es 2 verschiedene Wege cron zu aktivieren:

    • In der Raspbmc GUI unter Programs -> Raspbmc Settings -> System Configuration -> Service Management -> Cronjob Scheduler


    • Über SSH die Datei /home/pi/.xbmc/userdata/addon_data/script.raspbmc.settings/settings.xml bearbeiten und die Einstellung sys.service.cron auf “true” stellen.



    Wenn ein Script oder Befehl eine Ausgabe erzeugt (zB durch echo's) wäre es zudem ratsam die Ausgabe in den Mülleimer umzuleiten. Das erreicht man indem man hinter den Befehl/Script folgendes anhängt:

    Code
    >/dev/null 2>&1


    Erklärung:


    Alle Befehle und Programme, welche in der Bash gestartet werden, erhalten drei Kanäle zugewiesen:

    • Den Standardeingabekanal stdin, dieser hat die Nummer 0 (null). Normalerweise liest stdin Eingaben von der Tastatur, welche mit dem Terminal verbunden ist.
    • Den Standardausgabekanal stdout, dieser hat die Nummer 1 (eins). Normalerweise schreibt stdout Ausgaben auf den Bildschirm, welcher mit dem Terminal verbunden ist.
    • Den Standardfehlerkanal stderr, dieser hat die Nummer 2 (zwei). Normalerweise schreibt stderr Ausgaben auf den Bildschirm, welcher mit dem Terminal verbunden ist.


    Die erste Umleitung " >/dev/null " schickt die StandardAusgabe (stdout) nach /dev/null, also dem klassischen Mülleimer von Linux
    Das dahinter " 2>&1 " leitet Fehlermeldungen (stderr) auf den Kanal der StandardAusgabe (stdout) um und landet somit ebenfalls im Mülleimer


    Dadurch vermeidet man möglicherweise zu viele Logeinträge in /var/log/syslog


    Trotzdem werden schwerwiegende Fehler noch ins /var/log/syslog geschrieben und dort sollte auch der erste Ort sein wo ihr nachguckt wieso/weshalb/warum ein Befehl/Script über crontab nicht funktionieren will


    Wichtig ist aber das generell keine Ausgabe auf eure Konsole erfolgt! Wenn ihr also ein Script über crontab starten lasst, welches eine Ausgabe erzeugt und ihr sehen wollt, dann müsst ihr eine Umleitung in eine Datei verwenden!

    Code
    >>/tmp/ausgabe.txt 2>&1


    Erklärung:


    Die doppelte Umleitung " >> " steht fürs sog. append, also danach einfügen. Dadurch wird der Inhalt der Datei nicht bei jedem ausführen überschrieben sondern ans Ende eingefügt. Wohin ihr das schreiben lasst ist relativ egal, allerdings kann es je nach Umfang der Ausgabe eine Mehrbelastung für eure SD bedeuten und dessen Haltbarkeit reduzieren... Um das zu verhindern siehe > hier <
    Das dahinter " 2>&1 " macht wieder das selbe wie oben erklärt: Fehlermeldungen werden ebenfalls in die Datei umgeleitet.




    Ausserdem solltet ihr in euren Scripts immer mit Exit-Codes arbeiten damit das System bzw crontab auch weiss ob das Script erfolgreich oder fehlerhaft ausgeführt wurde.
    Wenn alles in Ordnung ist nutzt man "exit 0", das sollte immer am Ende des Scripts stehen.
    Wenn es Fehler gibt zB falsche Anforderungen die fürs Durchlaufen des Scripts erfüllt sein müssten oder weil en Befehl im Script einen Fehler verursacht hat, nutzt man alles über 0 also "exit 1" oder "exit 2" usw. Mehr zu den Exit-Codes könnt ihr hier nachlesen:






    Allgemein zu Scripts:



    Scripts sollten immer so aufgebaut sein das in der ersten Zeile der Interpreter (shebang) angegeben wird und in der letzten Zeile ein ' exit 0 ' steht damit anderen Scripts/Programmen ein positiver Rückgabewert gegeben werden kann ala "script wurde erfolgreich ausgeführt und beendet"


    Also so:

    Bash
    #!/bin/bash
    
    
    echo hallo
    
    
    exit 0


    Der Interpreter ist wichtig damit das Programm gewählt werden kann der den nachfolgenden Code verarbeiten soll bzw kann



    Interpreter:


    Ein Skript kann von unterschiedlichen Interpretern interpretiert werden - oder auch nicht.
    Es gibt einen POSIX-Standard, den die populären Shells alle ganz gut beherrschen. Was darüber hinaus geht kann die eine Shell aber die andere nicht, und die andere kann jenes, was erstere nicht kann oder anders löst.


    Wenn man einen Interpreter ausdrücklich aufruft (bash /path/to/script.sh), dann wird dieser verwendet - ohne wenn und aber; der Shebang schaut in die Röhre, wird also ignoriert.
    Natürlich kann man nicht erzwingen, dass das Skript in einem Interpreter funktionieren wird, für den es nicht geschrieben wurde. Das Skript wird ja nicht auf magische Weise umgeschrieben..


    Der Aufruf:


    Wenn man den Interpreter explizit aufruft, also beispielsweise


    Code
    bash script.sh



    dann muss man zuvor das Skript nicht ausführbar machen, weil man den Interpreter ausführt und das Skript dessen Eingabedatei ist, so wie zB ein Bild die Eingabe für ein Grafikprogramm wie Gimp ist.


    Lässt man den Interpreter weg, muss man das Skript erst ausführbar machen; dann wird der Shebang ausgewertet, der in der ersten Zeile steht und aus einem Kommentarzeichen

    Code
    #


    (engl.: sharp) besteht, dem

    Code
    !


    (engl.: bang) und dem Pfad zum Interpreter - üblicherweise dem absoluten Pfad, also /bin/bash oder /bin/sh
    insgesamt also:

    Bash
    #!/bin/bash



    • Bei Skripten mit Shebang werden vom Linuxkernel die SUID- und SGID-Flags ignoriert.
    • Mittels Shebang kann man ein Skript aufrufen, welches seinerseits wieder einen Shebang hat usw. Allerdings nur vier Rekursionstiefen tief, dann ist Schluss.
    • Der Shebang kann um Parameter erweitert werden:


      Bash
      #!/bin/bash -f


    • Skripte in anderen Sprachen wie Lua, Python, Ruby usw. lassen sich analog mit einem Shebang starten - sofern das # dort als Kommentar toleriert wird, also


      Python
      #!/usr/bin/python


      oder

      Code
      #!/usr/bin/php


    • Bei Skripten, bei denen man nicht weiß, auf welcher Linux-Plattform sie landen werden, findet man auch einen zweistufigen Aufruf, weil man beispielsweise nicht weiß, wo Lua installiert ist. Man ruft dann


      Code
      #!/usr/bin/env lua


      auf, und verlässt sich darauf, dass env einheitlich installiert ist, und damit lua im Pfad gefunden wird.


    Faustregeln


    Soweit nicht anders verordnet, nimmt man

    Bash
    #!/bin/bash


    als erste Zeile des Skripts.


    • Was mit der


      Code
      dash


      klappt und mit

      Code
      sh


      , das klappt fast immer auch mit der

      Code
      bash


      - umgekehrt aber nicht!

    • Die


      Code
      bash


      ist weit verbreitet und kommt auch bei Raspbian als interaktive Shell zum Einsatz.

    • Die


      Code
      bash


      ist viel mächtiger als

      Code
      sh


      . Die Zeit, die man beim Schreiben spart holt die schnellere Startzeit der sh niemals rein - außer man arbeitet in einer Umgebung, die es dringend gebietet mehr als Faustregeln zu lernen.

    • Die zsh ist auch sehr mächtig, aber Leute, die zsh-Tipps geben, wissen, dass kaum jemand die


      Code
      zsh


      nutzt. Deswegen schreiben sie dann auch ausdrücklich dazu, dass es zsh-Code ist.




    Bekannte Probleme:


    Da leider immer wieder Threads erstellt werden in denen die selben Problemchen behandelt werden, hier eine grobe Zusammenfassung der häufigsten Fehler im Umgang mit der crontab:


    Wichtig ist:
    - Der Benutzer der crontab hat das Recht die Datei auszuführen. Jeder Benutzer hat seine eigene crontab.
    - Zum Script und innerhalb des Scripts absolute Pfade verwenden. Ein Absoluter Pfad beginnt mit dem Wurzelverzeichnis " / ". Absolut: /usr/local/smarthome/scripts/SQLBackup.py Relativ: SQLBackup.py. Werden im Script irgendwelche Dateien geöffnet oder geschrieben müssen dafür ebenfalls Absolute Pfade gesetzt sein.
    - Wenn die gleiche Zeile (abgesehen von den ersten 5 Spalten zum Ausführzeitpunkt) manuell nicht funktioniert, kann crontab auch nicht zaubern.

  • Hallo allerseits,
    Ich habe mal noch eine Frage zu crontab/jobs:


    Ich habe ein Script über die crontab laufen welches fortwähren die Temperatur eines Sensors in eine log-Datei schreibt. Ich möcht natürlich jeden Tag eine neue (mit Datum) haben.
    Nach dem Schema %Y-%m-%d.log funktioniert es bei mir nicht. wenn ich einen normalen Dateinamen (temp.log) einstelle, funktioniert es korrekt.


    Hier meine crontab:


    */5 * * * * /home/pi/scripte/mrtg/update_mrtg_temp.sh >> /home/pi/Temp-%Y-%m-%d.log


    Hier mein Script:
    #!/bin/bash


    # Read temperature from sensor
    tempread=`cat /sys/bus/w1/devices/10-000802b57b2c/w1_slave`


    temp=`echo $tempread | egrep -o ".{5}$"`


    temp2=`echo "scale=2; $temp / 1000" | bc`


    # Update database
    echo $temp2
    echo 0
    echo 0
    echo temperature


    -----------------------------------------------------------------------------


    Was läuft falsch ?


    Das Script war ursprünglich für MRTG gedacht. Da ich aber nach langem Gefummel nicht hinbekommen habe das die Temperaturgraphen in MRTG dargestellt werden, nutze ich das Script nun auf diese Weise. Ohne die letzten 5 Zeilen läuft das Script nicht (gibt keine Temperaturwerte aus)


    Gruß
    crepp

  • Wenn die Logdatei ein Datums-Format haben soll musst du den Befehl date benutzen, also für deinen Crontab Eintrag zum Beispiel so:

    Code
    */5 * * * * /home/pi/scripte/mrtg/update_mrtg_temp.sh >> /home/pi/Temp-$(date +%Y-%m-%d).log


    oder so:

    Code
    */5 * * * * /home/pi/scripte/mrtg/update_mrtg_temp.sh >> /home/pi/Temp-`date +%Y-%m-%d`.log


    Welchen du davon nimmst ist egal, haben beide den selben Effekt (ich bevorzuge erstere Schreibweise)


    Wenn du das in der Konsole eingibst siehst du was der Rückgabewert ist:

    Code
    root@raspberry-pi:~# date +%Y-%m-%d
    2013-11-14
    root@raspberry-pi:~#
  • Hallo, danke für die Antwort
    Habs mal getestet: Im Terminal gibt er mir das Datum richtig aus.
    Wenn ich ich den Code in die crontab eingebe kommen Fehlermeldungen wg. der Schreibweise: (bei beiden Versionen) Die Ausgabe ohne die Datumsvariable läuft problemlos.
    Hast Du einen Tipp?
    Ausgabe im Mailer:
    From pi@raspberrypi1 Tue Nov 19 11:10:02 2013
    Return-path: <pi@raspberrypi1>
    Envelope-to: pi@raspberrypi1
    Delivery-date: Tue, 19 Nov 2013 11:10:02 +0100
    Received: from pi by raspberrypi with local (Exim 4.80)
    (envelope-from <pi@raspberrypi1>
    id 1ViiFu-00039x-6o
    for pi@raspberrypi1; Tue, 19 Nov 2013 11:10:02 +0100
    From: root@raspberrypi1 (Cron Daemon)
    To: pi@raspberrypi1
    Subject: Cron <pi@raspberrypi> /home/pi/scripte/mrtg/update_mrtg_temp.sh >> /home/pi/Temp-$(date +
    Content-Type: text/plain; charset=UTF-8
    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <HOME=/home/pi>
    X-Cron-Env: <PATH=/usr/bin:/bin>
    X-Cron-Env: <LOGNAME=pi>
    Message-Id: <E1ViiFu-00039x-6o@raspberrypi>
    Date: Tue, 19 Nov 2013 11:10:02 +0100


    /bin/sh: 1: Syntax error: end of file unexpected (expecting ")")



    From pi@raspberrypi1 Tue Nov 19 11:11:02 2013
    Return-path: <pi@raspberrypi1>
    Envelope-to: pi@raspberrypi1
    Delivery-date: Tue, 19 Nov 2013 11:11:02 +0100
    Received: from pi by raspberrypi with local (Exim 4.80)
    (envelope-from <pi@raspberrypi1>
    id 1ViiGr-0003BN-Qo
    for pi@raspberrypi1; Tue, 19 Nov 2013 11:11:01 +0100
    From: root@raspberrypi1 (Cron Daemon)
    To: pi@raspberrypi1
    Subject: Cron <pi@raspberrypi> /home/pi/scripte/mrtg/update_mrtg_temp.sh >> /home/pi/Temp-`date +
    Content-Type: text/plain; charset=UTF-8
    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <HOME=/home/pi>
    X-Cron-Env: <PATH=/usr/bin:/bin>
    X-Cron-Env: <LOGNAME=pi>
    Message-Id: <E1ViiGr-0003BN-Qo@raspberrypi>
    Date: Tue, 19 Nov 2013 11:11:01 +0100


    /bin/sh: 1: Syntax error: EOF in backquote substitution

  • Nee geht auch nicht ...


    From: root@raspberrypi1 (Cron Daemon)
    To: pi@raspberrypi1
    Subject: Cron <pi@raspberrypi> /home/pi/scripte/mrtg/update_mrtg_temp.sh >> /home/pi/Temp-`date '+
    Content-Type: text/plain; charset=UTF-8
    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <HOME=/home/pi>
    X-Cron-Env: <PATH=/usr/bin:/bin>
    X-Cron-Env: <LOGNAME=pi>
    Message-Id: <E1Viiph-0001Gt-TO@raspberrypi>
    Date: Tue, 19 Nov 2013 11:47:01 +0100


    /bin/sh: 1: Syntax error: EOF in backquote substitution

  • ...es wäre wirklich sehr nett wenn Ihr eure Problem nicht in den Tutorial Threads behandelt sondern wenn ihr euch einen eigenen Thread erstellt - denn wenn das hier jeder macht werden die Tutorial Threads sehr schnell unübersichtlich und man weiss garnicht mehr was davon Hilfreich ist oder eben nicht...


    :danke_ATDE:




    PS: Nur weil die Dateiendung ".sh" lautet, bedeutet das nicht das es sich um ein "sh" Script handelt... In der ersten Zeile im Script steht normalerweise der Shebang (also der Interpreter der den Code verarbeitet), wenn da aber "bash" drin steht muss das Script auch über "bash" ausgeführt werden da sh wesendlich älter als bash ist und nicht die selben Funktionen unterstützt


    Desweiteren wäre es bei Problembehandlungen sehr hilfreich wenn auch der Code (also das Script) und wie es aufgerufen wird, mit angegeben wird..

  • Ich hätte noch eine Frage zu einem Skript das den Befehl


    Code
    sudo ./send 11111 1 1


    verschicken soll .Das muss im Ordner


    Code
    raspberry-remote



    passieren.Nur wie muss der Befehl in crontab heißen ?
    Dieser Befehl ist schon mal falsch
    (z.B. jeden Tag im Monat von Montag bis Freitag um 06:00)

    Code
    00 06 * * 1,2,3,4,5 root raspberry-remote/sudo ./send 11111 1 1



    ,aber den Fehler find ich nicht.(Ich habe bisher mit crontab so noch nichts gemacht).

    :angel: praise the Raspberry Pi

  • Du musst den vollständigen Pfad angeben - jenachdem wo raspberry-remote liegt ... und ich glaube nicht das dort drin "sudo" liegt, aber vorallem brauchst du "sudo" nicht da du es ja bereits als root ausführen möchtest? Also völliges Chaos irgendwie


    Lies den ersten Beitrag bitte noch mal aufmerksam - dann solltest du nämlich eigentlich zum einen wissen wann man "root" in die Crontab eintragen kann/darf




    Und nochmals der Hinweis,der bereits im Post davor steht: Bitte nicht in diesem Thread mit euren speziellen Problemen ankommen - ich werd hiernach nicht mehr auf eure Probleme die in diesem Tutorial Threadd gepostet werden, reagieren

  • *** Hat sich erledigt ***
    (Habe gerade ein Systemupdate und anschliessendes Reboot gemacht - jetzt funktioniert es.)



    Hatte schon mal jemand ein Problem damit, ein Skript zu einem bestimmten Zeitpunkt auszuführen? Bei mir laufen die Skripte nur, wenn ich überall * benutze. Ein konkreter Zeitpunkt, oder gar nur die Angabe einer konkreten Stunden funktioniert nicht.


    geht nicht:

    Code
    * 1 * * * /home/pi/testCron


    geht:

    Code
    * * * * * /home/pi/testCron


    An dem eigentlichen Skript oder Rechten kann es also nicht liegen. Im Moment weiss ich mir nicht weiterzuhelfen :(


    Wäre toll, wenn jemand eine Idee hätte. Solange muss ich meine Kaffeemaschine leider noch selbst anschalten und kann nicht die Funksteckdose automatisch ansteuern (was der Zweck des eigentlichen Skripts sein soll).


    Gruß,
    Marc

    Edited once, last by MarcE ().

  • /home/pi/script.sh :

    Bash
    #!/bin/bash
    echo "Test " >> /tmp/test.log
    exit 0


    mittels 'bash' aus der Konsole als 'pi' aufgerufen funktioniert es auch.
    [...]


    Im OP werden die Skripte ohne 'bash ' in der crontab gestartet, das funktioniert bei mir aber genausowenig (bzw noch weniger, habe noch andere Skripte dort die mit den normalen Zeitangaben gestartet werden, die startet cron auch nur mit vorgestelltem 'bash ' ).


    Gruß MasterPi


    EDIT: den anderen Blödsinn hab ich wieder gelöscht, zwecks Übersichtlichkeit :^^:

    Edited once, last by MasterPi ().

  • Für Individuelle Probleme bitte einen eigenen Thread aufmachen - wenn wir in den Tutorial Threads jedes Problem behandeln wird es irgendwann sehr unübersichtlich :(



    Angaben zu Binary's bitte immer mit vollständigen Pfaden nutzen -> gibt man in der Konsole zB 'bash' ein, wird in den $PATH Verzeichnissen danach gesucht. In manchen Fällen kann es aber vorkommen das $PATH zu dem Zeitpunkt noch nicht gesetzt ist und er somit 'bash' nicht finden kann -> /bin/bash würde dann aber funktionieren.


    Desweiteren gibt man über den Shebang den Interpreter an, also das Programm welches den Text verarbeiten soll. Wenn man die Datei ausführbar macht und einen Shebang angibt wird also der auch verwendet. Man muss dann nicht zusätzlich die Datei direkt dem Interpreter übergeben sondern brauch nur die Datei ausführen.


    Üblicherweise nutzt man für eine neue Spalte TAB's (die Taste links über CAPSLOCK) und nicht Leerzeichen. Ggf verursacht das bei dir auch Probleme.


    Und zu guter letzt wäre auch die Zeile im syslog nach der Ausführung interessant, da stehen ggf auch noch Fehlermeldungen

  • Sorry, war ein Tippfehler in der crontab... Asche auf mein Haupt. :wallbash:
    Um die Übersichtlichkeit hier zu wahren (und meinen peinlichen Fehler zu verstecken;)) lösche ich mein Beispiel gleich wieder...


    Zu den zuletzt von dir genannten Fehlerquellen kann ich aber ausschließen:
    Tabs oder Leerzeichen machen keinen Unterschied.
    bash ist auch ohne vollständige Pfadangabe beim @reboot bekannt. Trotzdem ein guter Hinweis!


    Jedoch klappt das Ausführen der script.sh auch trotz bash-Shebang und execute bits nicht ohne vorangestelltes bash.

    Code
    -bash: script.sh: Kommando nicht gefunden.


    Ich benutze "Linux raspi2 3.12.19+ #682 PREEMPT Mon May 12 23:27:36 BST 2014 armv6l GNU/Linux" aber bei RaspBMC war das auch nicht anders. Eine De-/Raspbian Eigenart?


    Im syslog steht noch folgender Fehler von cron
    May 21 20:17:16 raspi2 /USR/SBIN/CRON[1904]: (CRON) info (No MTA installed, discarding output)
    Fehlender Mail Transfer Agent... Vielleicht kannst du darauf nochmal näher eingehen?


    Vielen Dank für deine Hilfe und sehr ausführliches Tutorial! :thumbs1:


    Warum forever nicht will, weiß ich jetzt zwar auch immernoch nicht, aber das ist dann wirklich ein individuelles Problem (bzw gehört hier nicht hin). Wenigstens kann ich jetzt auschließen, daß @reboot nicht geht...


    EDIT: mit /bin/sh als shebang klappt es jedoch


    Edited once, last by MasterPi ().


  • Jedoch klappt das Ausführen der script.sh auch trotz bash-Shebang und execute bits nicht ohne vorangestelltes bash.

    Code
    -bash: script.sh: Kommando nicht gefunden.


    Bist du sicher das du zum einen den richtigen Pfad zum Script angegeben hast und zum anderen das es sich bei der Datei um eine Linux-kompatible Datei handelt? -> Womit hast du die Datei angelegt/erzeugt? -> Windows verwendet andere Zeilenumbruch-Zeichen als es Linux tut, aber Linux kann die von Windows nicht verarbeiten.. Also am besten einfach die Datei noch mal löschen, mit nano neu anlegen und copy&paste



    Im syslog steht noch folgender Fehler von cron
    May 21 20:17:16 raspi2 /USR/SBIN/CRON[1904]: (CRON) info (No MTA installed, discarding output)
    Fehlender Mail Transfer Agent... Vielleicht kannst du darauf nochmal näher eingehen?


    /etc/crontab ist etwas besonderes. Nur da kann man bestimmte Variablen wie SHELL, PATH oder MAILTO einstellen. Bei letzterem würde bei einem Fehler ne EMail an die angegebene Adresse verschickt werden. Ich vermute mal dass das bei dir der Fall ist, aber eben kein MTA Dienst eingerichtet wurde?



    Warum forever nicht will, weiß ich jetzt zwar auch immernoch nicht, aber das ist dann wirklich ein individuelles Problem (bzw gehört hier nicht hin). Wenigstens kann ich jetzt auschließen, daß @reboot nicht geht...


    EDIT: mit /bin/sh als shebang klappt es jedoch


    Man kann auch direkt die Befehle rein schreiben zum Beispiel:

    Code
    @reboot   pi   /bin/echo "$(date) Test" >> /tmp/test.log



    Ansonsten bitte einen eigenen Thread erstellen!
    :danke_ATDE:

  • aha, also wenn ich '/home/pi/script.sh' aufrufe geht es. Ohne angabe eines Interpreters in der Konsole funktioniert wohl nur mit absolutem Pfad, obwohl man schon im richtigen Verzeichnis ist. Da muss man auch erstmal drauf kommen...


    MAILTO benutze ich selbst nirgends, cron versucht wohl auch dann eine Email zu schicken wenn ein Eintrag fehlschlägt?


    P.S. das Problem mit forever konnte ich auch lösen, musste vor dem Aufruf nochmal die PATH variable setzen. Aus deiner vorigen Erklärung schließe ich, daß beim @reboot die ~/.profile noch nicht ausgewertet wurde, der export PATH Eintrag dort also noch nicht gesetzt wird.
    Vielleicht kannst du den OP noch mit einem Hinweis darauf ergänzen...


    :danke_ATDE:


    PPS. nochwas zum Thema (crontab): lässt sich das logging im syslog irgendwie unterdrücken? Habe ein Skript das jede (halbe, mit 'sleep 30') Minute ausgeführt wird, das spamt den log ganz schön voll...


    EDIT: habe es nun selbst herausgefunden: 'sudo nano /etc/rsyslog.conf' und dann hier 'cron,' hinzugefügt:

    Code
    *.*;cron,auth,authpriv.none                         -/var/log/syslog

    deaktiviert logging von cron jobs

    Edited once, last by MasterPi ().

  • Ähm... Wenn man im richigen Verzeichnis ist und ein dortiges Programm (oder sonstiges executable) ausführen will, dann muss man ./ voranstellen.
    ./beispiel.py führt das Pythonscript beispiel.py im aktuellen Ordner aus. Wenn man keinen Punkt nutzt, sucht er den Befehl im PATH, also unter /bin, /usr/bin etc. Dort sucht er, solange kein Pfad angegeben ist, wo er suchen soll. Ein absoluter Pfad funktioniert daher, aber auch jeder beliebige (korrekte) relative Pfad. du könntest also auch ../ordner/script schreiben um script im aktuellen ordner zu starten.

  • Hi,


    das at Kommando muss - unter wheezy - als eigenes Package nachinstalliert werden.



    cu,
    -ds-

  • Hallo zusammen!
    Ich habe mir gestern einen neuen cronjob eingerichtet, der leider nicht wie gewünscht ausgeführt wurde. Was ich erreichen wollte: Ein Script alle 20 Minuten zwischen 23 und 7 Uhr laufen lassen. Hier der entsprechende crontab-Eintrag:

    Code
    */20 23-7 * * * sh /hier/bla.sh


    Der Eintrag, das Script zw. 8 und 22 Uhr alle 10 Minuten zu starten funktioniert problemlos:

    Code
    */10 8-22 * * * sh /hier/bla.sh


    In der man zu cron konnte ich nur das finden:

    Quote

    Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive. For example, 8-11 for an ``hours'' entry specifies execution at hours 8, 9, 10 and 11.


    Kann es sein, dass ranges immer geordnet sein müssen (also z.B. "8-20") und nicht über die "Tagesschwelle" rausgehen dürfen?

  • Ja - so in etwa habe ich es nun auch drin ("0-7,23"). Mal schauen, ob es damit klappt. Werde Rückmeldung geben.


    Edit: Funktioniert wunderbar!