Cronjob auf dem Raspberry Pi einrichten – crontab verstehen

NEWS



CRONJOB AUF DEM RASPBERRY PI EINRICHTEN – CRONTAB VERSTEHEN


Raspberry Pi Platine neben einer Sanduhr aus Messing auf einem Holztisch

Aufgaben nach Zeitplan: cron ist das Uhrwerk des Pi

Kurz gesagt: Wie richte ich einen Cronjob auf dem Raspberry Pi ein?

Ein Raspberry Pi Cronjob ist eine einzige Zeile in einer Textdatei, die den Rechner dazu bringt, einen Befehl immer wieder zur gewünschten Zeit auszuführen – ohne dass jemand davorsitzt. Die Kurzfassung:

  • Anlegen: crontab -e im Terminal öffnet die persönliche Aufgabenliste. Jede Zeile darin ist ein Auftrag, Zeilen mit # am Anfang sind Kommentare.
  • Fünf Zeitfelder: Minute, Stunde, Tag des Monats, Monat, Wochentag – danach folgt der Befehl. 30 2 * * * heißt „jeden Tag um 2:30 Uhr".
  • Kürzel statt Zahlen: @daily, @hourly, @weekly und vor allem @reboot sparen die Rechnerei.
  • Absolute Pfade sind Pflicht: Cron startet den Befehl in einer nahezu leeren Umgebung. python3 und ~/skript.sh funktionieren dort oft nicht, /usr/bin/python3 /home/pi/skript.py immer.
  • Ausgabe umleiten: Ohne >> /home/pi/logs/job.log 2>&1 verschwinden Meldungen und Fehler spurlos – dann tappt man bei der Fehlersuche im Dunkeln.
  • Moderne Alternative: systemd-Timer holen verpasste Läufe nach und protokollieren von selbst, brauchen dafür aber zwei Dateien statt einer Zeile.

Was ein Raspberry Pi Cronjob ist und wofür er taugt

Im Hintergrund von Raspberry Pi OS läuft ein kleiner Dienst namens cron. Er tut nichts anderes, als jede Minute einmal aufzuwachen, in seine Aufgabenlisten zu schauen und alles zu starten, was laut Zeitplan gerade fällig ist. Diese Aufgabenlisten heißen crontab, ein einzelner Eintrag darin ist der Cronjob. Der Dienst ist auf jedem Raspberry Pi OS bereits installiert und aktiv – es gibt nichts nachzuinstallieren.

Genau darin liegt der Reiz: Der Pi zieht wenige Watt und kann deshalb ohne schlechtes Gewissen durchlaufen. Ein Gerät, das ohnehin immer an ist, ist der ideale Ort für alles, was regelmäßig passieren soll – das nächtliche Backup, das stündliche Auslesen eines Temperatursensors oder das wöchentliche Aufräumen alter Dateien.

Wichtig ist die Abgrenzung zu zwei verwandten Dingen. Cron ist kein Autostart: Wer ein Programm dauerhaft laufen lassen will, ist mit einem Autostart-Dienst besser bedient. Und Cron ist keine Ereignissteuerung: Auf „wenn Datei X ankommt" reagiert er nicht, dafür sind Werkzeuge wie Node-RED gedacht.

Der große Vorteil von Cron ist seine Schlichtheit: keine Oberfläche, kein zusätzlicher Dienst – nur Textzeilen, die seit Jahrzehnten gleich aussehen und auf jedem Linux-System funktionieren. Der Preis dafür ist, dass Cron nichts verzeiht und Fehler nicht von selbst meldet.

Raspberry Pi Cronjob einrichten – Schritt für Schritt

  1. Befehl von Hand testen: Erst wenn er im Terminal sauber durchläuft, gehört er in die crontab. Ein eigenes Skript braucht #!/bin/bash als erste Zeile und das Recht zum Ausführen: chmod +x /home/pi/skripte/backup.sh.
  2. Vollständigen Pfad ermitteln: which python3 oder which rsync verraten, wo das Programm wirklich liegt. Genau diesen Pfad trägt man ein, nicht den kurzen Namen.
  3. crontab öffnen: crontab -e eingeben. Beim ersten Aufruf fragt das System nach dem Editor – nano ist für Einsteiger die richtige Wahl. Weitere Kommandos stehen in der Befehlsübersicht.
  4. Zeile eintragen: Ans Ende der Datei kommt der Auftrag, etwa 30 2 * * * /usr/bin/rsync -a /home/pi/daten/ /mnt/ssd/backup/ >> /home/pi/logs/backup.log 2>&1. Eine Kommentarzeile darüber erklärt in einem Jahr, worum es ging.
  5. Speichern und schließen: In nano mit Strg+O, Enter und Strg+X. Als Bestätigung erscheint crontab: installing new crontab. Bleibt sie aus, steckt ein Syntaxfehler in der Datei.
  6. Eintrag kontrollieren: crontab -l listet alle aktiven Aufträge des angemeldeten Benutzers. Was hier nicht steht, läuft auch nicht.
  7. Ersten Lauf beobachten: Zum Testen kurz */2 * * * * eintragen. journalctl -u cron -f zeigt live, ob Cron den Job startet, die eigene Logdatei zeigt das Ergebnis.
  8. Zeitplan scharf stellen: Läuft alles, kommt der echte Rhythmus hinein – und die Testzeile raus.

Die fünf Zeitfelder in der crontab – Aufbau und Beispiele

Jede Zeile beginnt mit fünf durch Leerzeichen getrennten Feldern. Danach folgt der Befehl, der ausgeführt werden soll:

FeldBedeutungWerte
1Minute0–59
2Stunde0–23
3Tag des Monats1–31
4Monat1–12 oder jan–dec
5Wochentag0–7 (0 und 7 = Sonntag) oder sun–sat

Vier Zeichen genügen für fast alles: * steht für „jeder Wert", , zählt einzelne Werte auf, - beschreibt einen Bereich und / einen Schrittabstand. Damit lassen sich alle üblichen Zeitpläne bauen:

ZeileBedeutung
*/5 * * * *alle fünf Minuten, rund um die Uhr
0 * * * *jede volle Stunde
30 2 * * *täglich um 2:30 Uhr nachts
0 3 * * 0jeden Sonntag um 3:00 Uhr
0 8-18 * * 1-5werktags stündlich zwischen 8 und 18 Uhr
*/10 6-22 * * *alle zehn Minuten, aber nur tagsüber
0 5 1,15 * *am 1. und am 15. jedes Monats um 5:00 Uhr
0 0 1 1 *einmal im Jahr, in der Neujahrsnacht

Die typische Anfängerfalle steckt in den Feldern drei und fünf: Sind beide gesetzt, verknüpft Cron sie mit „oder", nicht mit „und". 0 6 13 * 5 läuft also an jedem 13. und zusätzlich an jedem Freitag – nicht nur an Freitagen, die auf einen 13. fallen.

Für die Standardfälle gibt es Kürzel, die anstelle aller fünf Felder stehen: @hourly, @daily (gleichbedeutend mit @midnight), @weekly, @monthly und @yearly. Eine Sonderrolle hat @reboot: Diese Zeile wird einmal ausgeführt, wenn der Cron-Dienst nach dem Start hochkommt. Das eignet sich für kleine Aufräum- oder Meldeskripte, aber schlecht für Programme, die Netzwerk oder ein gemountetes Laufwerk brauchen – zu diesem Zeitpunkt ist längst nicht alles bereit. Ein pragmatischer Trick ist eine Wartezeit im Skript, sauberer ein systemd-Dienst mit passender Abhängigkeit.

Benutzer-crontab, System-crontab und /etc/cron.d im Vergleich

Cron liest nicht nur eine Datei, sondern mehrere Orte. Wer den Unterschied kennt, sucht später nicht vergeblich nach einem Job, der „irgendwo" eingetragen wurde:

OrtAnlegen mitBenutzerfeldWofür geeignet
Benutzer-crontabcrontab -eneineigene Skripte, Standardfall
root-crontabsudo crontab -eneinAufgaben mit Systemrechten, Neustart
System-crontabsudo nano /etc/crontabjawenige zentrale Aufträge
/etc/cron.d/nameeigene Datei je Aufgabejasaubere Trennung, leicht zu sichern
/etc/cron.daily/Skript hineinlegenSkripte ohne eigene Zeitangabe

Der entscheidende Unterschied: In /etc/crontab und in Dateien unter /etc/cron.d/ steht zwischen den Zeitfeldern und dem Befehl zusätzlich der Benutzername. Wer diese Spalte vergisst, bekommt keinen Fehler zu sehen – der Job läuft einfach nie. Ein gültiger Eintrag sieht so aus:

30 2 * * * pi /home/pi/skripte/backup.sh >> /home/pi/logs/backup.log 2>&1

Zwei weitere Eigenheiten sind gut zu wissen. Dateien unter /etc/cron.d/ werden ignoriert, wenn ihr Name einen Punkt enthält – backup.conf wird also nie gelesen, backup schon. Und die Verzeichnisse /etc/cron.daily/, .weekly und .monthly arbeiten Skripte ohne Zeitangabe ab; wann genau, steuert /etc/crontab beziehungsweise anacron. Wer sein System absichert, sollte außerdem bedenken: Nur Aufträge in der root-crontab laufen mit Systemrechten.

Die häufigste Fehlerquelle: Cron kennt deine Umgebung nicht

Wenn ein Cronjob „nicht funktioniert", liegt es meist nicht am Zeitplan, sondern an der Umgebung. Startet man einen Befehl selbst im Terminal, hat die Anmeldesitzung längst allerlei vorbereitet: einen langen Suchpfad für Programme, geladene Profildateien, Variablen aus .bashrc. Nichts davon existiert, wenn Cron den Befehl startet.

Konkret heißt das: Der Suchpfad einer Benutzer-crontab beschränkt sich auf /usr/bin:/bin. Programme unter /usr/local/bin, /sbin oder in einer Python-Umgebung findet Cron von sich aus nicht, und relative Pfade wie ./daten/messwerte.csv greifen ins Leere. Vier Gewohnheiten räumen das dauerhaft aus:

  • Alles absolut schreiben: /usr/bin/python3 /home/pi/skripte/messung.py statt python3 messung.py. Das gilt auch für Dateien, die das Skript selbst öffnet.
  • PATH oben in der crontab setzen: Eine Zeile PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin vor allen Aufträgen erspart viel Sucherei.
  • Ausgabe in eine Logdatei lenken: >> /home/pi/logs/job.log 2>&1 hängt Meldungen und Fehler an dieselbe Datei an. Ohne diesen Zusatz versucht Cron, die Ausgabe per Mail zuzustellen – da auf dem Pi normalerweise kein Mailserver läuft, ist sie schlicht verloren. MAILTO="" ganz oben unterdrückt diese Versuche.
  • Vor dem Aufruf ins richtige Verzeichnis wechseln: cd /home/pi/projekt && /usr/bin/python3 main.py löst alle Probleme mit relativen Pfaden auf einen Schlag.

Zwei Kleinigkeiten kosten zusätzlich Nerven. Erstens das Prozentzeichen: In der crontab steht % für einen Zeilenumbruch. Ein Dateiname mit Datumsstempel wie backup-$(date +%Y-%m-%d).tar.gz braucht deshalb zwingend die Rückstriche – sonst bricht der Befehl mitten im Namen ab. Zweitens die Zeitzone: Cron rechnet mit der Systemzeit. Steht die noch auf UTC, laufen alle Jobs zwei beziehungsweise eine Stunde daneben. timedatectl zeigt die aktuelle Einstellung, sudo timedatectl set-timezone Europe/Berlin korrigiert sie, und wer den Pi ohne Netzwerk betreibt, braucht zusätzlich eine Echtzeituhr oder einen NTP-Server im Netz. Bei der Sommerzeitumstellung verhält sich Cron gutmütig: Jobs mit fester Uhrzeit, die in die übersprungene Stunde fallen, werden nachgeholt, und bei der Rückstellung im Herbst nicht doppelt ausgeführt.

Lange Läufe absichern und systemd-Timer als Alternative

Ein Klassiker: Ein Job soll alle fünf Minuten Messwerte holen, braucht bei langsamer Verbindung aber gelegentlich acht. Cron startet trotzdem stur den nächsten Durchlauf, und nach einer Stunde arbeiten mehrere Instanzen gleichzeitig, die sich gegenseitig Dateien überschreiben. Die Lösung heißt flock und ist bereits installiert:

*/5 * * * * /usr/bin/flock -n /tmp/messung.lock /home/pi/skripte/messung.sh >> /home/pi/logs/messung.log 2>&1

Der Schalter -n bedeutet: Läuft schon eine Instanz, beendet sich der neue Aufruf sofort und stillschweigend. Wer lieber warten möchte, bis der Vorgänger fertig ist, verwendet -w 60 für ein Zeitlimit in Sekunden.

Seit systemd auf jedem Raspberry Pi OS läuft, gibt es eine zweite Möglichkeit: Timer-Units. Eine .service-Datei beschreibt, was passieren soll, eine gleichnamige .timer-Datei, wann. Der Zeitplan steht in der Zeile OnCalendar=*-*-* 03:00:00, geprüft wird er mit systemd-analyze calendar, aktiviert mit sudo systemctl enable --now backup.timer. systemctl list-timers zeigt anschließend alle Timer samt nächstem Termin.

KriteriumCronsystemd-Timer
Aufwandeine Zeilezwei Dateien plus Aktivierung
Verpasste Läufefallen auswerden mit Persistent=true nachgeholt
Protokollnur bei eigener Umleitungautomatisch im Journal
AbhängigkeitenkeineAfter=network-online.target und Ähnliches
Grenzen für CPU und RAMkeinepro Unit einstellbar
Mehrfachstartsmöglich, flock nötigvon Haus aus verhindert
Übertragbarkeitjedes Linux und Unixnur Systeme mit systemd

Die ehrliche Einordnung: Für den Einzeiler, der nachts ein Verzeichnis sichert, ist Cron schneller getippt und völlig ausreichend. Sobald ein Auftrag aber ein Laufwerk oder eine Netzwerkverbindung voraussetzt oder nach einem Stromausfall nachgeholt werden muss, spielt der Timer seine Stärken aus.

Typische Cronjobs auf dem Raspberry Pi im Alltag

Vier Aufgabentypen tauchen in Foren und Projektberichten immer wieder auf – sie decken den größten Teil dessen ab, wofür Cron auf einem Pi überhaupt gebraucht wird:

  • Sichern: Nachts um zwei kopiert rsync die Nutzdaten auf eine externe SSD oder aufs NAS. Ein vollständiges Abbild gehört dagegen nicht in einen Cronjob im laufenden Betrieb – dafür ist das Klonen der SD-Karte der sicherere Weg.
  • Aufräumen: find /home/pi/logs -type f -mtime +14 -delete löscht wöchentlich alles, was älter als zwei Wochen ist – und verhindert, dass irgendwann der Speicher vollläuft. Ausgerechnet die Logdateien der Cronjobs selbst sind dabei oft die größten Sünder.
  • Messwerte erfassen: Alle fünf oder zehn Minuten liest ein Python-Skript einen Sensor aus und hängt eine Zeile an eine CSV-Datei an. Ausgewertet wird das Ganze später in Grafana. Auch Zeitraffer-Aufnahmen entstehen nach demselben Muster.
  • Pflegen und neu starten: Ein wöchentliches apt update hält die Paketliste frisch – automatische Updates ohne Kontrolle sind aber mit Vorsicht zu genießen. Ein geplanter Neustart wie 0 4 * * 1 /sbin/shutdown -r now in der root-crontab ist eher Pflaster als Lösung: Er kaschiert Speicherlecks, statt sie zu beheben.

Fehler und Stolpersteine bei Cronjobs

  • Kein Log, keine Diagnose: Ohne Umleitung in eine Datei gibt es nichts zu untersuchen. Ob Cron einen Auftrag überhaupt gestartet hat, verrät journalctl -u cron --since "1 hour ago". Auf Systemen mit installiertem rsyslog hilft zusätzlich grep CRON /var/log/syslog; auf aktuellen Images fehlt diese Datei häufig, weil das Journal die Protokollierung übernimmt.
  • Skript ohne Ausführungsrecht: Fehlt chmod +x oder die Shebang-Zeile, startet gar nichts. Der Aufruf über /bin/bash /pfad/skript.sh umgeht das Problem.
  • Falscher Benutzer: Ein mit sudo crontab -e angelegter Job taucht bei crontab -l als normaler Benutzer nicht auf – und umgekehrt. Wer seinen Eintrag „verloren" hat, sucht meist in der falschen Liste.
  • Fehlende Rechte: Zugriff auf GPIO, /mnt-Verzeichnisse oder Systemdateien scheitert lautlos. Solche Aufträge gehören in die root-crontab.
  • Grafische Programme: Cron hat keine Bildschirmsitzung. Ohne DISPLAY=:0 startet kein Fenster – für Kiosk-Anwendungen ist ohnehin der Autostart der Oberfläche der richtige Weg.
  • crontab -r ist keine Rückgängig-Taste: Der Befehl löscht die komplette Liste sofort und ohne Nachfrage, und r liegt gefährlich nah an e. Eine Sicherung mit crontab -l > ~/crontab-sicherung.txt kostet Sekunden.
  • Zu viele Jobs zur vollen Stunde: Starten zehn Aufträge gleichzeitig um 0:00 Uhr, kämpfen sie um CPU und I/O. Ein paar Minuten Versatz entspannen die Lage spürbar.

Häufige Fragen zu Cronjobs auf dem Raspberry Pi

Muss ich cron erst installieren?
Nein. Der Dienst ist in Raspberry Pi OS enthalten und läuft ab Werk, auch in der Lite-Variante ohne Oberfläche. Mit systemctl status cron lässt sich das in zwei Sekunden bestätigen.

Warum läuft mein Skript im Terminal, aber nicht als Cronjob?
Weil Cron eine andere Umgebung hat: knapper Suchpfad, keine Profildateien, anderes Arbeitsverzeichnis. Absolute Pfade für Programme und Dateien lösen das in fast allen Fällen.

Was passiert, wenn der Pi zur geplanten Zeit ausgeschaltet ist?
Der Lauf fällt ersatzlos aus, Cron holt nichts nach. Wer Nachholbedarf hat, nutzt einen systemd-Timer mit Persistent=true oder installiert anacron.

Wie führe ich einen Job nur alle zwei Wochen aus?
Direkt geht das nicht, denn die Zeitfelder kennen keine Wochenzählung. Üblich ist ein wöchentlicher Job, der im Skript selbst über die Kalenderwoche entscheidet, ob er wirklich etwas tut.

Kann ich Cronjobs auch grafisch verwalten?
Ja, Weboberflächen wie Webmin bringen einen Cron-Editor mit. Für einzelne Einträge ist crontab -e per SSH aber meist schneller.

Wie oft darf ein Cronjob laufen?
Minütlich ist die feinste Auflösung. Für Sekundenintervalle sind Cronjobs das falsche Werkzeug – dafür gehört ein Dauerprozess her, etwa als systemd-Dienst.

Wie lasse ich mich bei Fehlern benachrichtigen?
Am einfachsten prüft das Skript selbst seinen Rückgabewert und schickt bei Problemen eine Nachricht, etwa über Telegram. Der eingebaute Mailversand von Cron ist auf dem Pi meist nicht eingerichtet.

Fazit

Ein Raspberry Pi Cronjob ist das schlichteste und zugleich nützlichste Werkzeug, das der Pi mitbringt: eine Textzeile, die aus einem Einplatinenrechner einen zuverlässigen Helfer macht, der nachts sichert, stündlich misst und wöchentlich aufräumt. Unsere klare Empfehlung: Fang mit der Benutzer-crontab an, schreibe konsequent absolute Pfade und häng an jeden Auftrag eine Logdatei – diese drei Gewohnheiten verhindern praktisch alle Anfängerprobleme. Für Aufträge, die länger dauern können, gehört flock dazu; und sobald ein Job Netzwerk, Laufwerke oder verpasste Läufe im Blick haben muss, ist der Umstieg auf einen systemd-Timer den zusätzlichen Aufwand wert. Wer sich dagegen fragt, ob ein Programm dauerhaft laufen soll statt regelmäßig zu starten, ist beim Autostart besser aufgehoben als bei Cron.

* = Affiliate Link (raspi-config.de ist Teilnehmer des Partnerprogramms von Amazon EU, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu Amazon.de Werbekostenerstattung verdient werden kann.)


VORSCHAU


Was Dich im Raspberry Pi Videokurs erwartet.


Play klicken & Video abspielen.

QUIZ


Prüfe Deinen aktuellen Wissensstand.

Raspberry Pi Quiz starten

Bild anklicken & Quiz starten.

NEWS



EMPFEHLUNG



Danke für Deine Weiterempfehlung!

© 2026 raspi-config.de | Datenschutz | Impressum