Anacron fuer Laptops und Desktops: Cron-Jobs zuverlaessig nachholen

1. Das Grundproblem: cron und nicht-permanent laufende Systeme

Klassisches cron geht von einer Grundannahme aus, die auf Servern zutrifft, auf Laptops und Desktops aber regelmaessig verletzt wird: Das System laeuft rund um die Uhr. Ist ein Rechner zum geplanten Ausfuehrungszeitpunkt eines Jobs ausgeschaltet oder im Suspend, wird der Job schlicht uebersprungen, ohne Fehlermeldung, ohne Log-Eintrag, ohne jede Benachrichtigung. Ein taeglicher Backup-Job, der um 02:00 Uhr laufen soll, wird auf einem Laptop, der jede Nacht ausgeschaltet wird, faktisch niemals ausgefuehrt.

Anacron wurde genau fuer dieses Szenario entwickelt und ergaenzt cron, statt es zu ersetzen. Anstatt Jobs an feste Uhrzeiten zu binden, arbeitet Anacron mit Intervallen in Tagen und prueft bei jedem Start, ob seit der letzten erfolgreichen Ausfuehrung genug Zeit vergangen ist. Ist das der Fall, wird der Job nachgeholt, unabhaengig davon, wie lange der Rechner zuvor ausgeschaltet war. Diese Denkweise macht Anacron zum idealen Werkzeug fuer alles, was nicht auf die Minute genau, aber zuverlaessig regelmaessig laufen muss.

2. Wie Anacron verpasste Jobs erkennt und nachholt

Das Kernprinzip von Anacron basiert auf Timestamp-Dateien im Verzeichnis /var/spool/anacron/. Fuer jeden konfigurierten Job existiert dort eine Datei, die das Datum der letzten erfolgreichen Ausfuehrung als einfache Zeichenkette speichert. Beim Start vergleicht Anacron dieses Datum mit dem konfigurierten Intervall in Tagen und dem aktuellen Datum. Ist die Differenz gleich oder groesser als das Intervall, gilt der Job als faellig und wird ausgefuehrt.

Nach erfolgreicher Ausfuehrung aktualisiert Anacron die Timestamp-Datei automatisch auf das aktuelle Datum. Wichtig zu verstehen: Anacron selbst laeuft nicht dauerhaft im Hintergrund wie ein Daemon, sondern wird typischerweise einmal taeglich ueber einen cron-Eintrag oder eine systemd-Unit angestossen, meist kurz nach dem Booten. Startet ein Laptop morgens um neun Uhr, prueft der naechste Anacron-Lauf sofort, ob taeglich oder woechentlich faellige Jobs nachgeholt werden muessen, und fuehrt sie mit einer konfigurierbaren Verzoegerung aus, um den Systemstart nicht sofort zu belasten.

3. /etc/anacrontab im Detail konfigurieren

Die zentrale Konfigurationsdatei /etc/anacrontab folgt einem eigenen, von cron abweichenden Format mit vier Spalten: Intervall in Tagen, Verzoegerung in Minuten nach dem Start, ein eindeutiger Job-Bezeichner und der auszufuehrende Befehl. Der Job-Bezeichner dient gleichzeitig als Dateiname fuer die Timestamp-Datei unter /var/spool/anacron/ und muss deshalb innerhalb der Datei eindeutig sein.

Auf den meisten Distributionen ist bereits eine Standardkonfiguration vorhanden, die die Verzeichnisse /etc/cron.daily/, /etc/cron.weekly/ und /etc/cron.monthly/ ueber Anacron statt direkt ueber cron ausfuehrt. Das erklaert, warum viele Distributionen diese drei Standardverzeichnisse auch dann zuverlaessig ausfuehren, wenn ein System nachts regelmaessig ausgeschaltet wird, waehrend individuelle crontab-Eintraege ohne Anacron-Anbindung tatsaechlich verpasst werden.

# /etc/anacrontab
# period  delay  job-identifier   command

# Run daily jobs, 5 minutes after anacron starts
1       5       cron.daily      run-parts --report /etc/cron.daily

# Run weekly jobs, 10 minutes after anacron starts
7       10      cron.weekly     run-parts --report /etc/cron.weekly

# Run monthly jobs, 15 minutes after anacron starts
@monthly 15     cron.monthly    run-parts --report /etc/cron.monthly

# Custom job: check disk space every 3 days
3       20      disk-check      /usr/local/bin/disk-space-check.sh

4. Eigene Anacron-Jobs anlegen

Fuer eigene Skripte gibt es zwei uebliche Wege: entweder wird ein Skript direkt in eines der Standardverzeichnisse /etc/cron.daily/, /etc/cron.weekly/ oder /etc/cron.monthly/ gelegt, oder ein eigener Eintrag wird direkt in /etc/anacrontab ergaenzt. Der erste Weg ist der pragmatischere fuer Standardintervalle, weil die Distribution die Anbindung an Anacron bereits uebernimmt und keine manuelle Konfiguration der Timestamp-Logik noetig ist.

Skripte in diesen Verzeichnissen muessen ausfuehrbar sein und duerfen keine Dateiendung tragen, da run-parts Dateien mit Punkten im Namen standardmaessig ignoriert, um versehentliche Ausfuehrung von Backup-Dateien wie skript.sh.bak zu verhindern. Fuer Intervalle, die von taeglich, woechentlich oder monatlich abweichen, etwa alle drei Tage, ist ein eigener Eintrag direkt in /etc/anacrontab die richtige Wahl, mit einem eindeutigen Job-Bezeichner und einer eigenen Verzoegerung, die nicht mit den Standardjobs kollidiert.

# Create a custom daily script
sudo tee /etc/cron.daily/backup-check <<'EOF'
#!/bin/bash
set -euo pipefail
/usr/local/bin/verify-backup-integrity.sh >> /var/log/backup-check.log 2>&1
EOF

# Make it executable and ensure no file extension
sudo chmod +x /etc/cron.daily/backup-check

# Check which anacron timestamp files already exist
ls -la /var/spool/anacron/

# Manually trigger anacron for testing (respects delays)
sudo anacron -f -n -t /etc/anacrontab

5. Anacron und cron sinnvoll kombinieren

Die sinnvolle Aufteilung zwischen Anacron und klassischem cron folgt einer einfachen Faustregel: Alles, was auf die Minute genau zu einer festen Uhrzeit laufen muss, etwa ein stuendlicher Datenabgleich, gehoert in cron. Alles, was nur regelmaessig innerhalb eines Tages, einer Woche oder eines Monats laufen muss, ohne dass die exakte Uhrzeit relevant ist, etwa eine woechentliche Log-Bereinigung, gehoert in Anacron. Beide Systeme laufen parallel und stoeren sich nicht gegenseitig, solange sie unterschiedliche Aufgaben abdecken.

Ein haeufiges Missverstaendnis: Anacron ersetzt cron nicht vollstaendig, sondern ergaenzt es gezielt fuer Faelle, in denen Zuverlaessigkeit wichtiger ist als Praezision. Auf einem Server, der ohnehin permanent laeuft, bringt Anacron kaum einen Vorteil gegenueber klassischem cron, weshalb es dort meist nur fuer die Standardverzeichnisse cron.daily und cron.weekly genutzt wird. Auf Laptops und Desktops hingegen ist die Kombination aus beiden Systemen die robusteste Loesung, um sowohl praezises Timing als auch garantierte Nachholung zu gewaehrleisten.

6. Die systemd-Alternative: Persistent-Timer als Ersatz

Wer bereits vollstaendig auf systemd-Timer umgestiegen ist, kann eine aehnliche Nachhol-Funktionalitaet ohne Anacron erreichen, indem in der Timer-Unit die Option Persistent=true gesetzt wird. Damit merkt sich systemd, wann ein Timer zuletzt ausgeloest wurde, und fuehrt ihn beim naechsten Boot sofort nach, falls der geplante Zeitpunkt waehrend einer Ausschaltphase verpasst wurde. Das Verhalten ist konzeptionell sehr aehnlich zu Anacron, aber tiefer in systemd integriert und ueber systemctl list-timers einheitlich mit anderen Timern sichtbar.

Der praktische Unterschied liegt in der Konfigurationssyntax und der Granularitaet: systemd-Timer mit OnCalendar erlauben deutlich flexiblere Zeitausdruecke als das einfache Tage-Intervall von Anacron, waehrend Anacron mit seiner einfachen Textdatei fuer viele Administratoren schneller zu ueberblicken bleibt. Fuer neue Desktop-Installationen, die ohnehin komplett auf systemd setzen, ist Persistent=true oft die modernere Wahl, waehrend bestehende Systeme mit etablierten cron.daily-Skripten meist problemlos bei Anacron bleiben koennen.

7. Anacron-Laeufe debuggen und Logs pruefen

Bei Problemen mit nicht ausgefuehrten Jobs ist der erste Schritt, die Timestamp-Dateien unter /var/spool/anacron/ zu pruefen. Ein Datum, das viel aelter ist als erwartet, deutet darauf hin, dass Anacron selbst nicht regelmaessig gestartet wird, etwa weil der zugrunde liegende cron-Eintrag oder die systemd-Unit fuer den Anacron-Aufruf selbst fehlt oder deaktiviert ist. Der Befehl anacron -f -n -t /etc/anacrontab erzwingt einen sofortigen Testlauf aller konfigurierten Jobs, unabhaengig vom letzten Ausfuehrungsdatum, was fuer die Fehlersuche unverzichtbar ist.

Fuer detailliertere Diagnose lohnt sich ein Blick in /var/log/syslog beziehungsweise journalctl -u anacron, wo Anacron protokolliert, welche Jobs es als faellig erkannt und ausgefuehrt hat. Die Option -d haelt Anacron zusaetzlich im Vordergrund und schreibt alle Debug-Ausgaben direkt auf die Konsole, was besonders hilfreich ist, wenn ein Skript innerhalb eines cron.daily-Verzeichnisses zwar ausgefuehrt, aber sein Ergebnis nicht wie erwartet sichtbar wird.

# Inspect timestamp files to see when jobs last ran
cat /var/spool/anacron/cron.daily
cat /var/spool/anacron/cron.weekly

# Check the system log for anacron activity
journalctl -u anacron --since "3 days ago"

# Force a full debug run in the foreground
sudo anacron -d -f -n -t /etc/anacrontab

# Verify run-parts correctly skips backup files
run-parts --list /etc/cron.daily

8. Typische Fallstricke im Desktop- und Laptop-Betrieb

Ein haeufiger Fehler ist die Annahme, Anacron reagiere auf Suspend-to-RAM genauso wie auf ein vollstaendiges Herunterfahren. Bei einem Laptop, der nur in den Ruhezustand versetzt und nie komplett neu gestartet wird, laeuft Anacron unter Umstaenden gar nicht erneut an, weil der zugrunde liegende Trigger, meist ein taeglicher systemd-Timer oder ein cron-Eintrag, ebenfalls von Suspend betroffen ist. Fuer solche Setups sollte zusaetzlich systemd-timer mit WakeSystem=true in Betracht gezogen werden, um das System gezielt aus dem Suspend zu wecken.

Ein zweiter Fallstrick betrifft Skripte, die von einer bestehenden Netzwerkverbindung ausgehen. Wird ein taeglicher Backup-Job direkt nach dem Systemstart per Anacron ausgeloest, bevor eine WLAN-Verbindung tatsaechlich steht, schlaegt der Upload zu einem entfernten Speicherziel fehl, ohne dass Anacron selbst einen Fehler meldet, weil Anacron lediglich die Ausfuehrung protokolliert, nicht aber deren inhaltlichen Erfolg. Ein robustes Skript sollte deshalb selbst pruefen, ob die benoetigte Netzwerkverbindung besteht, und bei Fehlschlag einen klaren Exit-Code zurueckgeben, der sich ueber run-parts --report im Log wiederfindet.

9. Anacron, cron und systemd-Timer im Vergleich

Die Wahl zwischen den drei Scheduling-Mechanismen haengt davon ab, wie kritisch exaktes Timing gegenueber garantierter Nachholung ist.

In der Praxis schliessen sich die drei Ansaetze nicht aus, sondern ergaenzen sich: cron fuer zeitkritische Aufgaben, Anacron oder Persistent-Timer fuer alles, was regelmaessig, aber nicht minutengenau laufen muss, und explizites Wecken aus dem Suspend nur dort, wo es wirklich erforderlich ist.

10. Zusammenfassung

Anacron loest ein Problem, das klassisches cron auf nicht-permanent laufenden Systemen strukturell nicht loesen kann: verpasste Jobs werden nicht stillschweigend uebersprungen, sondern beim naechsten Start automatisch nachgeholt. Die Konfiguration ueber /etc/anacrontab mit Intervall in Tagen, Verzoegerung und eindeutigem Job-Bezeichner ist einfach, aber ausreichend fuer die meisten Wartungsaufgaben auf Laptops und Desktops. Die Standardverzeichnisse cron.daily, cron.weekly und cron.monthly laufen auf den meisten Distributionen bereits ueber Anacron.

Fuer moderne systemd-basierte Systeme bietet Persistent=true in Timer-Units eine vergleichbare Nachhol-Funktionalitaet mit flexiblerer Zeitangabe ueber OnCalendar. Die robusteste Strategie kombiniert cron fuer zeitkritische Aufgaben mit Anacron oder Persistent-Timern fuer alles, was regelmaessig, aber nicht exakt zur Minute laufen muss, ergaenzt um netzwerkbewusste Skripte, die auch nach einem verspaeteten Start korrekt funktionieren.

11. FAQ: Anacron fuer Laptops und Desktops