Cron & Anacron

  • ich hoffe, dass dieses tutorial euch etwas weiter bringt. viel glück !


    CRON & ANACRON

    Inhaltsverzeichnis

    CRON & ANACRON 1

    1. CRON 1

    1.1 Installation 1

    1.2 Cronjobs manuell einrichten 2

    1.3 Umleitungen 5

    2. ANACRON 9

    1. CRON

    Der Cron-Daemon ist ein Dienst, der automatisch Skripte und Programme zu vorgegebenen Zeiten starten kann. Der auszuführende Befehl wird in einer Tabelle, der crontab, gespeichert. Es gibt eine systemweite Datei /etc/crontab, die nur mit Root-Rechten bearbeitet werden kann. Diese beinhaltet folgende Zeilen :

    # /etc/crontab: system-wide crontab

    # Unlike any other crontab you don't have to run the `crontab'

    # command to install the new version when you edit this file

    # and files in /etc/cron.d. These files also have username fields,

    # that none of the other crontabs do.

    SHELL=/bin/sh

    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

    # Example of job definition :

    # .---------------- minute (0 - 59)

    # | .------------- hour (0 - 23)

    # | | .---------- day of month (1 - 31)

    # | | | .------- month (1 – 12) OR jan,feb,mar,apr ...

    # | | | | .---- day of week (0 – 6) (Sunday=0 oder 7) OR sun,mon,tue,wed,thu,fri,sat

    # | | | | |

    # * * * * * user-name command to be executed

    17 * * * * root cd / && run-parts --report /etc/cron.hourly

    25 6 * * * root test -x /usr/sbin/anacron | | (cd/ && run-parts --report /etc/cron.daily)

    Zusätzlich kann jeder Benutzer eine eigene Crontab erstellen, die man dann im Verzeichnis /var/spool/cron/crontabs/ findet.

    Diese Tabelle besteht also aus sieben beziehungsweise sechs Spalten. Die ersten fünf dienen der Zeitangabe (Minute, Stunde, Tag, Monat, Wochentage) für einen Cronjob, dann folgt (nur in der systemweiten Crontab) der Benutzername, unter dem der Befehl ausgeführt werden soll. Die letzte Spalte enthält letztendlich den auszuführenden Befehl. Die einzelnen Spalten werden durch Leerzeichen oder Tabulatoren getrennt.


    Hinweis:

    Sollte während der automatisierten Ausführung ein Fehler auftreten, so versucht Cron, diese Fehlermeldung per E-Mail an den Systemadministrator beziehungsweise den Benutzer zu senden. Dies ist allerdings nur möglich, wenn ein sogenannter Mail Transfer Agent oder kurz MTA – wie beispielsweise Postfix - installiert ist.

    1.1 Installation

    Der Dienst und seine Verwaltungswerkzeuge für die Kommandozeile ist in dem RaspianOS Buster bereits im Paket cron enthalten. Zudem können Cronjobs auch über eine GUI (grafisches User-Interface) bearbeitet werden. Für zahlreiche auf der Grafikbibliothek GTK basierenden Desktop-Umgebungen gibt es dafür das Programm GNOME Schedule. Nähere Informationen findet man auf der Seite von GNOME Schedule.

    1.2 Cronjobs manuell einrichten

    Eine Crontab für einen Benutzer einrichten

    Um eine eigene Tabelle für einen Benutzer einzurichten, muss man ein Terminal-Fenster öffnen und den folgenden Befehl zum Editieren der Tabelle eingeben :

    crontab -e

    Aus historischen Gründen wird eine Crontab mit einem Kommandozeileneditor bearbeitet. Wurde noch kein Editor festgelegt, erscheint folgende Auswahl :

    no crontab for BENUTZERNAME - using an empty one

    Select an editor. To change later, run 'select-editor'.

    1. /bin/ed

    2. /bin/nano <---- easiest

    3. /usr/bin/jmacs

    4. /usr/bin/joe

    5. /usr/bin/jpico

    6. /usr/bin/jstar

    7. /usr/bin/rjoe

    8. /usr/bin/vim.tiny

    Choose 1-8 [2]:

    Der ausgewählte Editor wird in der versteckten Datei ~/.selected_editor im Homeverzeichnis gespeichert. Möchte man die getroffene Entscheidung später wieder ändern, löscht man diese Datei oder benutzt wie angegeben den Befehl :

    select-editor

    Alternativ dazu, falls man den Editor nur für die aktuelle Bearbeitung ändern möchte, kann dieser auch direkt angegeben werden (hier am Beispiel von nano) :

    EDITOR = nano crontab -e

    Besaß der Benutzer bisher noch keine Crontab, so enthält die Datei nur ein paar Kommentare. Hier ein Beispiel für eine Crontab :

    #-----------------------------------------------------------------

    # Shell variable for cron

    SHELL=/bin/bash

    # PATH variable for cron

    PATH=/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11

    #M S T M W Befehl

    #-----------------------------------------------------------------

    5 9-20 * * * /home/BENUTZERNAME/script/script1.sh > /dev/null

    */10 * * * * /usr/bin/script2.sh > /dev/null 2>&1

    59 23 * * 0,4 cp QUELLDATEI ZIELDATEI

    * * * * * DISPLAY=:0 LANG=de_DE.UTF-8 zenity --info --text

    0 0 * * * backup

    #-----------------------------------------------------------------

    Im ersten Abschnitt stehen die Angaben für die Variablen PATH und SHELL. Im unteren Teil folgen die einzelnen Cronjobs. In einer Zeile kommen zuerst die fünf Felder für die Zeiten (Minute, Stunde, Tag, Monat, Wochentage) und danach der auszuführende Befehl. In diesem Beispiel werden die Befehle

    • 5 Minuten nach jeder vollen Stunde zwischen 9 und 20 Uhr (also 9:05, 10:05, ..., 20:05)

    • alle 10 Minuten

    • jeden Sonntag und Donnerstag um 23:59

    • jede Minute ein Programm mit GUI, das die Display- und die Sprach-Variable benötigt

    • jeden Tag Punkt Mitternacht 00:00 Uhr

    ausgeführt.


    Hinweis :

    Wichtig ist, dass am Ende der Tabelle ein Kommentar (#) oder eine Leerzeile steht (dazu die <ENTER>-Taste drücken).

    Erzeugt der durch den Cron-Daemon aufgerufene Befehl eine Ausgabe, so wird alles, was auf der Konsole ausgegeben wird, an den Benutzer per E-Mail geschickt, unter dessen Benutzerkonto der Befehl ausgeführt wurde. Möchte man dies nicht, so muss man die Ausgabe umleiten.

    Als Beispiel soll nun ein Server daraufhin überprüft werden, ob dieser online ist. Hierzu wird alle fünf Minuten ein Ping an den Rechner geschickt. Ein erfolgreicher Ping ist uninteressant. Im Falle eines Fehlers sollte jedoch der Cronjob eine E-Mail mit dem Ergebnis des gescheiterten Pings ausgeben. Dies wird erreicht, indem man die Standardausgabe stdout an /dev/null umleitet.

    Fehlermeldungen werden dadurch - wie gewünscht – verschickt, und das erfolgreiche Ergebnis verworfen.

    */5 * * * * ping -c 1 192.168.0.1 > /dev/null

    Möchte man keinerlei Ausgaben des Cronjobs erhalten - beispielsweise bei einem regelmäßigen Ping an eine Internetadresse, um zu verhindern, dass die Dial-Up-Verbindung getrennt wird - so muss die Weiterleitung wie folgt aussehen :

    */5 * * * * ping -c 1 http://www.google.de > /dev/null 2>&1

    Dadurch wird jegliche Ausgabe des Cronjobs verworfen. Mehr Informationen zur Weiterleitung findet man unter 1.3 Umleitungen.

    Hier ist noch kurz eine Übersicht, wie der Cronjob aufgebaut ist :

    * * * * * Befehl der ausgeführt werden soll

    - - - - -

    | | | | |

    | | | | +----- Wochentag (0 - 7) (Sonntag ist 0 und 7; oder Namen)

    | | | +----------- Monat (1 - 12)

    | | +----------------- Tag (1 - 31)

    | +----------------------- Stunde (0 - 23)

    +----------------------------- Minute (0 - 59; oder Namen)

    Für die Wochentage und die Monate können die drei ersten Buchstaben des englischen Namens benutzt werden, beispielsweise Sun für Sonntag. Groß-/Kleinschreibung spielt dabei keine Rolle, allerdings sind keine Angaben von Zeiträumen erlaubt, dazu müssen Ziffern verwendet werden.

    Setzt man beispielsweise für die Spalte Stunde 8-10, wird der Befehl in den Stunden 8, 9 und 10 Uhr ausgeführt. Statt der Schreibweise 8-10 könnte auch 8,9,10 geschrieben werden.

    Setzt man hingegen */2 in diese Spalte, dann wird der Befehl jede zweite Stunde ausgeführt. Beides kann auch kombiniert werden: so bedeutet beispielsweise 1-9/2 dasselbe wie 1,3,5,7,9.

    Man sollte jedoch bedenken, dass beispielsweise die Zeichenfolge * */2 * * * den Befehl 60 mal - also zu jeder Minute - jede zweite Stunde ausführt.

    Zur Vereinfachung können die ersten fünf Felder auch durch eine einzelne Zeichenkette ersetzt werden. Hierfür sind die folgenden acht Schlüsselwörter definiert :

    String Bedeutung cron-Schreibweise

    @reboot einmalig, beim Start

    @daily einmal pro Tag 0 0 * * *

    @midnight einmal pro Tag 0 0 * * *

    @hourly einmal pro Stunde 0 * * * *

    @weekly einmal pro Woche 0 0 * * 0

    @monthly einmal im Monat 0 0 1 * *

    @annually einmal im Jahr 0 0 1 1 *

    @yearly einmal im Jahr 0 0 1 1 *


    Benachrichtigungen für bestimmte Benutzer versenden

    Mit der MAILTO-Variable kann ein Empfänger für die Benachrichtigungen unabhängig vom Besitzer der Cron-Tabelle festgelegt werden (MAILTO=irgendwer). Wird die Variable als inhaltsleer deklariert (MAILTO=""), so werden keine Benachrichtigungen versendet.


    Cron-Tabelle des Benutzers Root

    Natürlich kann auch root eine Crontab anlegen. Alle Cronjobs, die in dieser Tabelle stehen, werden mit Root-Rechten ausgeführt :

    sudo crontab -e


    Die systemweite Cron-Tabelle /etc/crontab

    Möchte man jedoch einen Cronjob erstellen, der mit speziellen Rechten ausgeführt werden soll, so bietet es sich an, diesen Job in die systemweite Cron-Tabelle einzutragen. Diese Tabelle unterscheidet sich nicht stark von einer normalen Cron-Tabelle, sie besitzt jedoch eine weitere Spalte, in welche der Benutzer eingetragen wird, unter dem der jeweilige Befehl ausgeführt werden soll.

    # /etc/crontab: system-wide crontab

    # Unlike any other crontab you don't have to run the `crontab'

    # command to install the new version when you edit this file.

    # This file also has a username field, that none of the other crontabs do.

    SHELL=/bin/sh

    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

    # m h dom mon dow user command

    17 * * * * root run-parts --report /etc/cron.hourly

    59 23 * * * username /pfad/zu/skript.sh

    Dies ist besonders nützlich, wenn Server, die ihren eigenen Benutzer haben, wie beispielsweise Apache mit www-data, über cronjobs gesteuert werden sollen. Oder wenn man für Benutzer Jobs anlegen möchte, die der Nutzer jedoch selber nicht verändern können soll.


    Hinweis :

    Neben der /etc/crontab werden auch alle Dateien im Verzeichnis /etc/cron.d/ von Cron gelesen. Dieses Verzeichnis ist dafür gedacht, dass Pakete, die eigene Cronjobs mitbringen, diese dort ablegen können. Es wird empfohlen, für eigene Cronjobs jedoch die /etc/crontab zu verwenden.

    Ruft man die manpage für crontab mit man crontab auf, so wird die manpage für das Programm crontab angezeigt. Die manpage für die Struktur der Tabelle bekommt man zu Gesicht, wenn man man 5 crontab aufruft - 5 steht für die Gruppe der Konfigurationsdateien.

    1.3 Umleitungen

    Beim Arbeiten im Terminal bietet die Bash verschiedene Möglichkeiten an, die Ausgabe (stdout) der einzelnen Befehle umzuleiten beziehungsweise an andere Befehle weiterzuleiten. Ebenso besteht die Möglichkeit, dass Befehle, die standardmäßig von der Standardeingabe (stdin) lesen, alternativ die Eingabe(n) auch aus einer Datei lesen können.

    In diesem Tutorial wird primär auf die Bash Bezug genommen. Die Umleitungen > , >>, < , << und | stehen in anderen POSIX-kompatiblen Shells jedoch in gleicher Form zur Verfügung.

    Alle Umleitungen gelten für den Prozess, für den sie eingerichtet werden, sowie für dessen Kind-Prozesse. Die Umleitungen können dort allerdings wieder überschrieben werden. Diese Eigenschaft sorgt dafür, dass bei Umleitung der Ausgabe eines Shell-Skriptes sämtliche Ausgaben in dem Skript in denselben Kanal – beispielsweise eine Datei - geschrieben werden.


    stdin, stdout, stderr - Kanäle der Bash

    Vorab noch ein wenig Hintergrundwissen :

    Allen Befehlen und Programmen, welche in der Bash gestartet werden, werden immer die drei folgenden Kanäle zugewiesen :

    • den Standardeingabekanal stdin; dieser hat die Nummer 0 (null). Normalerweise liest stdin die Eingaben von der Tastatur, welche mit dem Terminal verbunden ist.

    • den Standardausgabekanal stdout; dieser hat die Nummer 1 (eins). Normalerweise schreibt stdout die Ausgaben auf den Bildschirm, welcher mit dem Terminal verbunden ist.

    • den Standardfehlerkanal stderr; dieser hat die Nummer 2 (zwei). Normalerweise schreibt stderr die Ausgaben auf den Bildschirm, welcher mit dem Terminal verbunden ist.

    Umleiten der Ausgabe mit >

    Mit Hilfe des "Größer als" Zeichens > lässt sich die Standardausgabe stdout umleiten. Eine typische (und sehr häufige) Anwendung ist das Umleiten in eine Datei. So schreibt beispielsweise der folgende Befehl

    ls > verzeichnis.txt

    den Inhalt des aktuellen Verzeichnisses in die Datei verzeichnis.txt anstatt in das Terminal.


    Achtung !

    Existiert die Datei verzeichnis.txt nicht, so wird diese angelegt. Existiert die Datei bereits, so wird diese ohne Rückfrage überschrieben, falls die Shell-Option -C ("noclobber") nicht gesetzt ist, was der standardmäßig der Fall ist !


    Experten-Info :

    Aus demselben Grund funktioniert beispielsweise nicht :

    sed s/muster/ersetzungstext/ < datei.txt > datei.txt

    Da die Öffnung des umgeleiteten Ausgabekanals - die damit einhergehende Löschung des Inhalts von datei.txt - der Öffnung des Eingabekanals vorausgeht, arbeitet sed mit einer leeren Datei.

    Es ist aber auch möglich, die Ausgabe an existierende Dateien anzuhängen, in dem man anstelle von > einfach >> verwendet. Der folgende Befehl

    ls ~/Desktop >> verzeichnis.txt

    hängt den Inhalt von ~/Desktop also an die Datei verzeichnis.txt an.

    Neben stdout schreibt auch der Standardfehlerkanal stderr regelmäßig auf das Terminal. Möchte man die Ausgabe von stderr umleiten, muss man 2> anstelle von > verwenden :

    ls -la /home/user 2> fehler.txt

    2> heißt soviel wie “leite den Kanal 2 (stderr) um“.


    Hinweis :

    Der Kanal 1 (stdout) muss bei der Umleitung nicht explizit benannt werden. > wird von der Bash automatisch mit 1> gleichgesetzt.

    Es lassen sich auch beide Kanäle gleichzeitig in zwei verschiedene Dateien umleiten :

    ls -la > verzeichnis.txt 2> fehler.txt

    So wird die Ausgabe von ls in die Datei verzeichnis.txt umgeleitet, Fehlermeldungen in die Datei fehler.txt. Weiterhin ist es auch möglich, beide Kanäle in eine Datei umzuleiten :

    ls -la > gemeinsam.txt 2>&1

    2>&1 bedeutet also soviel wie “schreibe die Ausgabe von Kanal 2 (stderr) dorthin, wo die Ausgabe von Kanal 1 (stdout) geschrieben wird“.


    Hinweis :

    Die Reihenfolge ist wichtig !

    Es wird immer dorthin umgeleitet, wohin der angegebene Kanal gerade umgeleitet wird. Stellt man beispielsweise 2>&1 vor das > gemeinsam.txt, wird stderr auf die Standardausgabe geleitet, und nur das, was ursprünglich auf die Standardausgabe geschrieben wurde, landet in der Datei.

    Natürlich kann man auch bei Kanal 2 >> verwenden. Somit lassen sich dann auch beispielsweise Fehlermeldungen während einer Datensicherung von Tar an eine Logdatei anhängen :

    echo "Sicherung" >> backup.log

    tar -cf sicherung.tgz "/home" 2>> backup.log

    Die Verwendung von &> leitet sowohl stdout als auch stderr in die angegebene Datei um. Das ist hilfreich unter anderem in Bash-Skripten, in denen lediglich der Rückgabewert von Befehlen interessiert, nicht aber der Ausgabetext. Diese Funktionalität ist nicht verfügbar in der Shell. Das nachfolgende Beispiel beendet ein Skript, wenn irgendeine Datei im Homeverzeichnis geöffnet ist und unterdrückt dabei jegliche Ausgaben :

    1 if lsof ~ &>/dev/null; then

    2 exit 1;

    3 fi

    In den Bash-Versionen 3.x und älter funktioniert die Umleitung mit &>> nicht, wobei alle aktuell unterstützen Raspbian-Versionen Bash 4.x mitbringen. Bei der Verwendung von den Versionen 3.x und älter kann man sich mit dem Anhängen von stdout an eine Datei und der anschließenden Umleitung von stderr nach stdoutweiterhelfen ;) . Das folgende Beispiel führt ein Kommando aus und hängt sowohl stdout als auch stderr an ein logfile :

    ./my_command.sh >> results.log 2>&1

    Für interaktive Shells empfiehlt es sich deshalb, die Shell-Option -C ("noclobber") zu verwenden, beispielsweise in der ~/.bashrc, die das versehentliche Überschreiben von Dateien verhindert :

    $ cat datei

    welt

    $ set -C

    $ echo star > datei

    bash: datei: cannot overwrite existing file

    $ cat datei

    welt

    Muss man dann doch einmal eine Datei überschreiben, hilft >| :

    $ echo star >| datei

    $ cat datei

    star

    Für einen Shell-Prozess inklusiver seiner Kindprozesse lässt sich die Ausgabe mittels :

    exec > datei.txt

    auch global umleiten. Bei sämtlichen in diesem Abschnitt genannten Varianten wird die Ausgabe aller nachfolgenden Befehle in die Datei geschrieben. Eine explizite Umleitung ist dann in den Befehlen nicht mehr erforderlich. Dies kann auch dazu genutzt werden, selektiv in eine Datei auszugeben, die nicht immer wieder geöffnet werden muss :

    exec 9> arbeit.log

    echo 'Wir zeigen das aktuelle Verzeichnis auf der Konsole an.' >&9

    ls

    echo 'Wir sind fertig mit dem Zeigen das aktuellen Verzeichnisses.' >&9

    Dieses Vorgehen spart Zeit für das Öffnen der Datei, hat aber vor allem den Vorteil, dass alle Ausgaben garantiert in derselben Datei landen. (Andernfalls wenn beim Arbeiten mit >> die Datei umbenannt wird, gelangen die Ausgaben in verschiedene Dateien.)


    Experten-Info :

    Normalerweise müssen Kanäle nicht geschlossen werden, da der Kernel das beim Beenden eines Prozesses automatisch tut. Sollte es in seltenen Fällen dennoch nötig sein, kann man das durch die Umleitung von/oder auf &- erreichen. Damit wird der umgeleitete Kanal geschlossen. Im obigen Beispiel mit exec würde Kanal 9 mit exec 9>&- geschlossen werden.


    Umleitung der Eingabe mit <

    Mit Hilfe des ‘Kleiner als‘-Zeichens < lässt sich die Standardeingabe (stdin) umleiten.


    Beispiel :

    tr -d '0-9' < datei.txt

    Dieser Aufruf zeigt den Inhalt aus datei.txt ohne Ziffern an.

    Bei Verdoppelung des Zeichens << kann man auf der Standardeingabe auch eine Pseudodatei erzeugen (das sogenannte Hier-Dokument), die dann sequenziell gelesen wird. Hinter dem Zeichen ist ein Schlüsselwort einzugeben, welches das “Dateiende“ symbolisiert.


    Beispiel :

    while read d

    do

    touch $d

    done << eod

    aufdieplaetze.txt

    fertig.txt

    los.txt

    eod

    In dem Beispiel werden in einem Durchgang drei Dateien mit den im Hier-Dokument enthaltenen Namen erzeugt.


    Der Pipe-Operator |

    Der Pipe-Operator (Pipe = Kurzform für Pipeline) leitet die Ausgabe eines Befehls direkt an einen anderen Befehl weiter (anstatt ans Terminal). Damit kann der zweite Befehl das Ergebnis bzw. die Ausgabe des ersten Befehls weiterverarbeiten. Man kann natürlich auch mehr als zwei Befehle miteinander verbinden. Die allgemeine Syntax lautet :

    Befehl1 | Befehl2


    Hinweis:

    Das Zeichen für den Pipe-Operator | erhält man auf einer deutschen Tastatur durch Drücken von Alt Gr + <.

    Eine typische Anwendung für den Pipe-Operator ist beispielsweise das Aufrufen eines Befehls, der eine größere Menge an Daten auf stdout schreibt. Dies sind zum Beispiel die Ausgaben von Systemmeldungen wie dmesg oder auch die Ausgaben von Prozessinformationen wie ps und pstree. Eine Kombination mit einer Datensortierung wie sort oder dem Durchsuchen der Ausgabe nach bestimmten Ausdrücken mit grep ist ebenfalls möglich. Hierzu nun einige Beispiele :

    Im ersten Beispiel werden alle laufenden Prozesse durch ps ausgegeben, der Pipe-Operator leitet die Ausgabe an sort um, das diese Daten sortiert - beispielsweise eine absteigende numerische Sortierung, Option -nr - und gibt diese (um)sortierten Daten dann an stdout weiter :

    ps ax | sort -nr

    Im zweiten Beispiel gibt dmesg alle Log-Meldungen des Kernels aus, der Pipe-Operator leitet diese um an grep. grep sucht nur nach Zeilen, in denen der Ausdruck USB vorkommt. Die Ausgabe von grep erfolgt dann (standardmäßig) auf stdout (der Parameter -n sorgt dafür, dass grep die Zeilen nummeriert).

    dmesg | grep -n USB

    Im dritten Beispiel kommen mehrere Pipelines zum Einsatz. Dazu wird der Befehl im zweiten Beispiel sowohl durch einen weiteren Pipe-Operator als auch durch den Befehl tail ergänzt. Somit werden nur noch die letzten zehn Zeilen angezeigt :

    dmesg | grep -n USB | tail

    Natürlich lässt sich der Pipe-Operator auch mit der Umleitung von stdin und stdout kombinieren, was im folgendem Beispiel ersichtlich wird :

    grep usb < alle-meldungen.log | tail > usb-meldungen.log


    Hinweis :

    Die Umleitungen müssen übrigens nicht direkt hinter dem Befehl stehen, sie können auch davor oder mittendrin geschrieben werden :

    grep < alle-meldungen.log usb | >usb-meldungen.log tail

    2. ANACRON

    anacron anac(h)ronistic cron wird benutzt um Kommandos periodisch, ähnlich wie bei cron auszuführen. anacron ist (im Gegensatz zu cron) für Systeme ausgelegt, die nicht dauerhaft laufen (z.B. Desktops oder Server, die nachts und/oder am Wochenende abgeschaltet werden). Als Ergänzung zu cron bietet sich daher anacron an. Anstatt einer crontab muss nur das auszuführende Skript oder Programm in das entsprechende Verzeichnis des Anacron-Dienstes kopiert oder verlinkt werden. anacron ist unter der GNU GPL (General Public License) lizenziert und in der aktuellen Version in C implementiert.


    Funktion

    Sie können mit anacron tägliche, wöchentliche und monatliche Kommandos ausführen lassen. anacron arbeitet im Gegensatz zu cron nicht mit definierten Zeitpunkten (Stunden, Minuten, Wochentagen, etc), sondern mit Zeitstempeln. Bei der Ausführung liest anacron eine Liste von Jobs aus einer Konfigurationsdatei – normalerweise ist dies /etc/anacrontab .Diese Datei enthält die Liste der Jobs, welche von anacron gesteuert werden. Jeder Jobeintrag gibt hierbei einen Zeitraum an (in Tagen), eine Verzögerung (in Minuten), eine eindeutige Job-ID, und einen (Shell-) Befehl. Eine Aufgabe wird zu allererst ausgeführt, und anschließend der Zeitstempel der letzten Durchführung im Format YYYYMMDD gespeichert. Wenn der Zeitstempel einer täglichen Aufgabe auf den Vortag datiert ist, führt anacron diese Aufgabe am aktuellen Tag aus, und erneuert den Zeitstempel dementsprechend. Wenn keine Jobs mehr ausgeführt werden müssen, wird anacron beendet. Die Konfiguation erfolgt, wie bereits erwähnt, in der Datei anacrontab , wohingegen die Zeitstempel im Verzeichnis /var/spool/anacron/ abgelegt werden. Die Skripte, die anacron ausführt, werden in den Verzeichnissen /etc/cron.daily|weekly|monthly abgelegt. Es werden nur diejenigen Jobs von anacron berücksichtigt, deren Kennung und Befehle aus den beiden Dateien anacrontab und cron.* übereinstimmen.


    Hinweise

    Stündliche Aufgaben werden also per cron ausgeführt, was auch einen installierten cron-Daemon auf dem System bedingt. Ebenso ist darauf zu achten, dass die Zeitzone korrekt gesetzt ist, da diese sonst (negative) Auswirkungen auf die Zeitstempel hat. anacron überprüft also bei jeder Aufgabe, ob diese entsprechend der Konfiguration bereits ausgeführt wurde. Ist dies nicht der Fall, führt anacron die Aufgabe möglichst zeitnah zum ursprünglichen Zeitpunkt aus.


    Installation

    anacron wird mittels der folgenden Befehle installiert :

    sudo apt update

    sudo apt-get install anacron


    Verzeichnisse und Dateien

    anacron verwendet verschiedene Dateien und Verzeichnisse. Sie werden nachfolgend aufgeführt und die Funktionsweise von anacron erläutert. Am besten schaut man sich kurz die Skripte in diesen Verzeichnissen an, bevor man selbst dort etwas ablegt.


    Hinweis :

    Der Skriptname darf nur große und kleine Buchstaben, Ziffern, Unterstriche und Bindestriche enthalten. Andernfalls wird das Skript nicht ausgeführt. Das exakte Zeichenalphabet wird durch folgenden regulären Ausdruck definiert : ^[a-zA-Z0-9_-]+$. Punkt und Umlaute sind also beispielsweise nicht erlaubt.


    /etc/anacrontab

    Möchte man Jobs stündlich, täglich, wöchentlich oder monatlich ausführen, muss dafür keine Konfiguration für Anacron vorgenommen werden. Es ist aber möglich, die Perioden zu verändern. Dazu ändert man die Konfigurationsdatei /etc/anacrontab.


    Die Datei erwartet folgendes Format :

    * * * Befehl der ausgeführt werden soll

    | | |

    | | +------------ job-identifier (Datei für den Zeitstempel)

    | +------------------ delay (Zeitverzögerung nach Systemstart in Minuten)

    +---------------- ------- period (Zeit in Tagen)


    Beispiel für period-Angabe:

    1 täglich

    7 wöchentlich

    30 monatlich

    Es ist jede andere Zahl möglich. Für monatliche Jobs kann als Periode auch @monthly verwendet werden.

    Feld Bedeutung

    period Periode der Jobausführung in Tagen

    delay Startverzögerung des Jobs nach Systemstart (in Minuten)

    job-identifier Zeitstempel-Datei, in welche der Zeitstempel geschrieben wird, damit der Job innerhalb der Periode nur einmal ausgeführt wird, beispielsweise bei täglichen Aufgaben und/oder mehrmaligem Start des Systems an einem Tag.

    Command Befehl oder auszuführendes Skript.

    In der Datei anacrontab im Verzeichnis /etc befinden sich nicht nur die Konfigurationen der Parameter SHELL, PATH und HOME für anacron, sondern auch die Einträge, welche die Scripte in cron.* ausführen. Parameter können gegebenenfalls angepasst oder hinzugefügt werden, wie beispielsweise MAILTO. Wie auch in der /etc/crontab ist es in der /etc/anacrontab möglich, vom System automatisch E-Mails versenden zu lassen :

    MAILTO="user@localhost"

    Für den E-Mail-Versand muss ein MTA (Mail Transfer Agent) wie beispielsweise Postfix installiert sein. Nachfolgend die Standardeinstellungen in der /etc/anacrontab

    dirk@raspberrypi: ~# cat /etc/anacrontab

    # /etc/anacrontab: configuration file for anacron

    # see anacron(8) and anacrontab(5) for details.

    SHELL=/bin/sh

    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

    HOME=/root

    # These replace cron's entries

    1 5 cron.daily run-parts –report /etc/cron.daily

    7 10 cron.weekly run-parts –report /etc/cron.weekly

    @monthly 15 cron.monthly run-parts –report /etc/cron.monthly

    Die stündlichen Jobs werden von anacron nicht behandelt und weiterhin von cron ausgeführt :

    $ grep hourly /etc/crontab

    17 * * * * root cd / && run-parts --report /etc/cron.hourly


    Achtung :

    Die Skripte in den cron.* Verzeichnissen dürfen keine Endung aufweisen, da sie sonst nicht ausgeführt werden ! Ungültig wäre z.B. rsnapshot.conf :

    #!/bin/sh

    rsnapshot hourly | | echo "Backup failure"

    $ sudo chmod +x /etc/cron.hourly/rsnapshot

    Analog dazu erstellt man die Skripte in cron.daily, cron.weekly und cron.monthly und ersetzt zugehörig hourly mit daily, weekly und monthly.

    Die Konfigurationseinträge cron.daily, cron.weekly und cron.monthly sollten unverändert bleiben. anacron liest diese Einträge und führt beispielsweise durch die nachfolgende Zeile einmal täglich alle in /etc/cron.daily abgelegten Skripte aus :

    1 5 cron.daily run-parts --report /etc/cron.daily

    Nach dem Systemstart wird 5 Minuten gewartet, bis diese Skripte ausgeführt werden. Nach der erfolgreichen Ausführung aller Skripte in /etc/cron.daily wird dann der Zeitstempel der Datei cron.daily im Ordner /var/spool/anacron/ neu gesetzt. Entscheidend für die Ausführung eines Scriptes ist der sogenannte shebang. Dies ist eine der häufugsten Fehlerquellen, weswegen ein Cronjob nicht ausgeführt wrden kann.


    /var/spool/anacron/

    Des weiteren gibt es das Verzeichnis /var/spool/anacron/. Hier werden die Zeitstempel der einzelnen Aufgaben abgelegt.

    root@raspberrypi:~# ls -la /var/spool/anacron/

    total 20

    drwxr-xr-x 2 root root 4096 Mai 11 10:57 .

    drwxr-xr-x 6 root root 4096 Mai 10 17:05 ..

    -rw------- 1 root root 9 Mai 12 09:26 cron.daily

    -rw------- 1 root root 9 Mai 11 11:26 cron.monthly

    -rw------- 1 root root 9 Mai 11 11:26 cron.weekly

    Hier sieht man die Zeitstempel der anacron-Aufgaben. In diesem Beispiel hat cron.daily den Zeitstempel 12.05.2020. Dies bedeutet, dass an diesem Tag die tägliche(n) Aufgabe(n) durchgeführt wurde(n). Diese Aufgabe wird somit an diesem Tag nicht mehr durchgeführt. Am folgenden Tag wird der tägliche Job erneut ausgeführt und ein neuer Zeitstempel 20200513 eingefügt.

    root@raspberrypi:~# cat /var/spool/anacron/cron.daily 20200512

    root@raspberrypi:~# cat /var/spool/anacron/cron.weekly 20200511

    root@raspberrypi:~# cat /var/spool/anacron/cron.monthly 20200511


    /lib/systemd/system/anacron.service

    Diese Datei bietet den systemd-Dienst für anacron.


    /lib/systemd/system/anacron.timer

    Diese Datei enthält den systemd-Timer für anacron. Derzeit wird der Dienst stündlich über den systemd-Timer ausgelöst.


    Tipps und Tricks

    Zugriff auf GNOME-Keyring ermöglichen

    Konfigurationen wie beispielsweise Offlineimap benötigen je nach Einrichtung einen Zugriff auf den GNOME-Schlüsselring. Dazu muss die DBUS_SESSION_BUS_ADDRESS als Umgebungsvariable gesetzt sein. Ein mögliches Szenario besteht darin, nach der Anmeldung die Variable zu exportieren und die Adresse in einer versteckten Konfiguration im Homeverzeichnis zu hinterlegen. Der Cronjob kann dann auf die entsprechenden Werte zurückgreifen und so Zugriff auf den Schlüsselbund erlangen. Dazu ist folgendes Startscript zu erstellen :

    1 #!/bin/bash

    2 # Exportiere die dbus session address, damit sie via Cron nutzbar ist

    3 # Diese Datei muss via Autostart ausgeführt werden

    4

    5 touch $HOME/.Xdbus

    6 chmod 600 $HOME/.Xdbus

    7 env | grep DBUS_SESSION_BUS_ADDRESS > $HOME/.Xdbus

    8 echo 'export DBUS_SESSION_BUS_ADDRESS' >> $HOME/.Xdbus

    Danach muss das Script via Autostart ausgeführt werden. Nun können im Cronjob mit

    source $HOME/.Xdbus; [BEFEHL]

    die benötigten Angaben verfügbar gemacht werden.


    Häufige Fehler

    Befehl klappt in Skript und Shell, aber nicht im Cronjob

    Vermutlich wurde die PATH-Variable nicht, wie oben im Beispiel, gesetzt und Cron findet Kommandos nicht, die von der Konsole fehlerfrei funktionieren. Cron benutzt von sich aus nicht die PATH-Variable des Users, sondern PATH="/usr/bin:/bin", sodass man entweder einen anderen PATH definieren oder die benutzten Programme mit vollem Pfad aufrufen muss.

    Wenn ein Skript in der Konsole funktioniert, nicht aber wenn es über die systemweite Cron-Tabelle gestartet wird, kann das daran liegen, dass sich das Startverhalten einer Shell über eine Cron-Tabelle von dem einer Loginshell unterscheidet. In diesem Fall sollte man das Skript anpassen oder folgenden Befehl in die Cron-Tabelle eintragen:

    /bin/bash --login /PFAD/ZUM/SKRIPT.sh


    Datums-Formate (wie beispielsweise $(date +"%Y%m%d") für Dateinamen oder Log-Ausgaben

    Während in einem Skript und der Shell eine Formatierung wie :

    echo cron-test1-$(date +"%Y%m%d-%H_%M") >> /tmp/cron-test.txt

    problemlos Funktioniert, so werden die %-Zeichen in Cron als Zeilenumbruch interpretiert und es kommt somit zu Fehlern. Als Problemlösung bietet sich an, entweder die Befehle über eigene Skripte auszuführen, oder man setzt vor jedes %-Zeichen einen Backslash \. Für obiges Beispiel lautet der entsprechende Eintrag in der crontab dann wie folgt :

    */2 * * * * heinz echo cron-test1-$(date +"\%Y\%m\%d-\%H_\%M") >> /tmp/cron-test.txt


    Anacron

    Wenn Anacron verwendet wird, darf im Dateinamen kein Punkt enthalten sein ! Mehr zu den Dateinamen findet man hier : Hinweis :


    Fenster einer Anwendung öffnet sich nicht

    Cron hat von Haus aus keinen Zugriff auf den Bildschirm. Cron ist in erster Linie für Server gedacht, die oftmals an gar keinen Bildschirm angeschlossen sind. Die Ausgabe der Kommandos wird auch nicht auf den Bildschirm geschrieben - das könnte auch sehr störend sein - sondern in Logdateien, bzw. in Mails, sofern eingerichtet, die an den Benutzer oder Administrator geschickt werden. Will man ausdrücklich ein Fenster öffnen, so muss man die Display-Variable setzen :

    DISPLAY=:0

    Manchmal muss auch noch die Lokalisation eingestellt werden, damit manbeispielsweise die deutsche Oberflächen erhält und Umlaute funktionieren :

    LANG=de_DE.utf8

    Unter bestimmten Desktopumgebungen wie LXDE ist es zusätzlich nötig, die XAUTHORITY-Variable auf einen "vernünftigen" Wert zu setzen, um Programme mit grafischer Oberfläche starten zu lassen. Dies könnte beispielsweise unterhalb der Zeile geschehen, in der die PATH-Variable gesetzt wird (PATH=/usr/local/bin:/usr/local/sbin...). Hierzu fügt man einfach folgende Zeile - mit angepasstem Benutzernamen – ein :

    XAUTHORITY=/home/[BENUTZERNAME]/.Xauthority

    Der Benutzername ist durch denjenigen zu ersetzen, der den Befehl crontab -e abgesetzt hat.


    Syslog

    Informationen über die Aktivitäten von anacron werden an syslog übermittelt.


    Optionen

    -f    erzwinge die Ausführung der Jobs und ignoriere die Zeitstempel

    -u    aktualisiere nur die Zeitstempel der Jobs mit aktuellem Datum, führe jedoch nichts aus

    -s die Ausführung der Jobs erfolgt in Serie, das heißt anacron startet keinen neuen Job, bevor der vorherige beendet ist

    -n    führe sofort Jobs aus. Ignoriere dabeidie Verzögerungsspezifikationen in der Datei /etc/anacrontab. Diese Option impliziert -s

    -d    in diesem Modus gibt anacron Informationsmeldungen an stderr sowie an syslog aus. Die Ausführung von Jobs wird dadurch nicht beeinträchtigt.

    -q Nachrichten auf stderr unterdrücken. Gilt nur für -d.

    -t anacrontab

    verwende anstelle der Standardeinstellung die Konfiguration aus der Datei anacrontab

    -T    anacrontab-Tests. Die Konfigurationsdatei wird auf Gültigkeit geprüft. Wenn die Datei einen Fehler enthält, wird ein Fehler angezeigt und anacron gibt 1 zurück. Gültige anacrontabs geben 0 zurück.

    -S spooldir

    verwende das angegebene Spool-Verzeichnis, um Zeitstempel zu speichern. Diese Option ist für Benutzer erforderlich, die anacron selbst ausführen möchten.

    -V Versionsinformationen anzeigen und anacronbeenden

    -h    gebe eine kurze Nutzungsnachricht aus und beende anacron.


    Debian-spezifische Konfiguration

    Auf Debian-basierten Systemen wird anacron jeden Tag stündlich von 07:30 bis 23:30 Ortszeit durch cron-Job (auf Systemen, auf denen cron installiert und aktiviert ist) oder durch System-Timer (auf Debian-basierten Systemen) aktiviert. Bei der Aktivierung prüft anacron, ob einige Jobs verpasst wurden. Wenn ja, werden diese nach kurzer Zeit gestartet.

    Standardmäßig findet die stündliche Aktivierung von anacron aber nicht statt, wenn das System einen Akku verwendet und kein Wechselstrom an den Computer angeschlossen ist. Es soll den Stromverbrauch reduzieren und die Batterielebensdauer verlängern. Zuständig dafür ist die Datei /usr/lib/pm-utils/power.d/anacron. Ein solches Design kann jedoch zu unerwünschten Ergebnissen führen. Benutzer können diese Funktion deaktivieren und anacron unabhängig von der Stromversorgung laufen lassen. Dazu bitte die Debian-spezifische Dokumentation in der Datei /usr/share/doc/anacron/README.Debianlesen ,um detaillierte Anweisungen zu erhalten, wie dieses Verhalten geändert werden kann.

  • Hallo,


    cron und anacron sind veraltet. Stand der Dinge sind systemd Timer Units. Alles, was darin steht, wird sowieso vom systemd in systemd Timer Units gewandelt. Direkt eine systemd TImer Unit nutzen ist aber flexibler, weil systemd mehr Möglichkeiten bietet als cron.


    Gruß, noisefloor

  • Steht bei mir im Systemd.Index auch nicht drinnen. < man systemd.index >

    Dass die (uralte) SysV Logik überhaupt noch funktioniert, ist den SysV-Generatoren von Systemd zu verdanken.



    Servus !

    RTFM = Read The Factory Manual, oder so

  • https://kofler.info/systemd-timer-als-cron-alternative/ zeit deutlich, was für ein Schwachsinn der systemd-Timer ist

    Quote

    Es gibt aber auch Nachteile: So wird bei einem Fehler nicht automatisch eine E-Mail versendet. Außerdem gibt es keine zufällige Verzögerung (RANDOM_DELAY in anacrontab), um die gleichzeitige Ausführung vieler Jobs zu vermeiden.

    Sicher, das gleichzeitige Ausführen vieler Jobs verhindert cron auch nicht, aber eine halbe Rechnerkonfiguration durchzuführen, wenn eine einzige Zeile, die (meiner Meinung ach auch noch einfach zu verstehen ist) ist nur eins: DÄMLICH.


    (genauso dämlich, wie bei normalen Cron-Jobs die System-Cron zu bearbeiten.

    Die User-Crons gibt es aus genau dem Grund, dass man nicht am System basteln muss,

    Auch werden bei den Benutzer-Corns diese auch automatisch mit den den nächsten lauf eingebunden. Was ja beim Systemd-Timer nicht so ist.

    Es gibt einiges am Systemd das, richtig und wichtig ist, doch das ist nur Mist.

    Selber denken,
    wie kann man nur?

    • Official Post

    Hat Cron ein offizielles EOL? :-/


    Ob Cron aktuell oder was auch immer ist spielt keine Rolle, die wird nun mal von den Leuten verwendet. Solange das so ist, kann ein Tutorial mehr nicht schaden.


    Perlchamp Du hast Dir die ganze Arbeit gemacht, auch deshalb stelle ich das Tutorial wieder her.


    Btw. Wer sich darüber beschweren will, kann das gerne machen. Hier meine Adresse: /dev/null