Warum systemd-Timer den Cronjob ablösen

Cron macht genau eine Sache: Es startet zur eingetragenen Zeit einen Befehl. Was danach passiert, interessiert es nicht. Läuft der Befehl auf einen Fehler, landet die Ausgabe im besten Fall in einer lokalen Mail, die niemand liest, und im schlechteren Fall in /dev/null, weil das jemand vor drei Jahren so eingetragen hat, damit das Log nicht zuläuft. Wie diese Umleitung funktioniert, haben wir in stdout, stderr und /dev/null auseinandergenommen – bei Cron ist sie der häufigste Grund, warum ein Fehlschlag unbemerkt bleibt.

Falls ihr Cron bisher klassisch benutzt habt, etwa für die Hintergrundaufgaben einer Nextcloud, kennt ihr die Bedienung aus unserer Anleitung Cronjob für Eure Nextcloud erstellen. Alles, was dort steht, funktioniert weiterhin. Es gibt nur eben inzwischen einen zweiten Weg.

Amazon ist dabei am deutlichsten geworden. In der Dokumentation zu Amazon Linux 2023 steht schwarz auf weiss: „In AL2023, cronie is not included by default. Therefore, support for crontab is no longer provided by default." Und weiter: „We recommend that you migrate to systemd timers due to the added functionality provided by systemd." Nachzulesen in der AL2023-Dokumentation zu Cron. Auf Debian, Ubuntu und Mint ist Cron weiterhin installiert – aber ein wachsender Teil der Systemwartung läuft dort ohnehin schon über Timer-Units, ohne dass es jemand gemerkt hätte.

Der praktische Unterschied lässt sich in eine Tabelle packen:

Die letzte Zeile ist der ehrliche Teil. Wer alle fünf Minuten ein Einzeiler-Skript anstossen will und sonst nichts, ist mit Cron schneller fertig. Für alles, dessen Ausfall wehtut – Sicherungen, Zertifikatserneuerungen, Datenbankpflege – lohnt sich der Mehraufwand ab dem ersten stillen Fehlschlag.

Voraussetzungen und eine Vorwarnung

Ihr braucht ein System mit systemd. Das trifft auf Debian, Ubuntu, Linux Mint, Fedora, openSUSE und Arch zu, also auf praktisch alles, was auf dieser Seite sonst behandelt wird. Prüfen lässt sich das mit:

systemctl --version

Für Units im Systemkontext braucht ihr Root-Rechte. Alle folgenden Befehle mit sudo setzen voraus, dass euer Benutzer das darf. Wer sich bei Benutzern, Gruppen und Rechten unsicher ist, findet die Grundlagen in Linux Gruppen und Berechtigungen einfach erklärt.

Wichtig: Legt eigene Units immer unter /etc/systemd/system/ ab, niemals unter /lib/systemd/system/ oder /usr/lib/systemd/system/. Das zweite Verzeichnis gehört der Paketverwaltung, und das nächste Update überschreibt eure Datei kommentarlos.

Die zwei Dateien: eine Service-Unit und eine Timer-Unit

Ein systemd-Timer führt selbst nichts aus. Er ist ausschliesslich der Wecker; die Arbeit macht eine Service-Unit. Die Handbuchseite systemd.timer(5) beschreibt die Zuordnung so: Ein Timer namens foo.timer aktiviert standardmässig die Unit foo.service, also den gleichen Namen mit anderer Endung. Solange ihr beide Dateien gleich benennt, müsst ihr die Verbindung nirgends eintragen.

Als durchgehendes Beispiel dient eine nächtliche Sicherung des Home-Verzeichnisses. Das eigentliche Skript liege unter /usr/local/bin/backup-home.sh und sei ausführbar.

Schritt 1: Die Service-Unit anlegen

sudo nano /etc/systemd/system/backup-home.service

Inhalt:

[Unit]
Description=Naechtliche Sicherung des Home-Verzeichnisses
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-home.sh
User=mario
Nice=10
IOSchedulingClass=idle

Drei Zeilen verdienen eine Erklärung. Type=oneshot ist der Typ für Aufgaben, die anlaufen, ihre Arbeit tun und sich beenden. Laut systemd.service(5) betrachtet der Dienstmanager die Unit erst dann als gestartet, wenn der Hauptprozess sich beendet hat – „the service manager will consider the unit up after the main process exits". Genau das wollt ihr hier, denn eine Sicherung ist fertig oder nicht.

User=mario lässt das Skript unter eurem Benutzer laufen statt als Root – ersetzt den Namen, und lasst die Zeile weg, falls das Skript Root braucht. Nice=10 und IOSchedulingClass=idle drängen den Job hinter interaktive Arbeit zurück; die Sicherung darf zehn Minuten länger dauern, wenn dafür niemand ruckelt.

Es fehlt eine Zeile, die ihr aus Cron kennt: die Umleitung der Ausgabe. Die braucht es nicht. Alles, was das Skript auf stdout und stderr schreibt, landet ohne Zutun im Journal – so beschreibt es systemd.exec(5) im Abschnitt zu Logging und Standard-Ein- und -Ausgabe.

Schritt 2: Die Timer-Unit anlegen

sudo nano /etc/systemd/system/backup-home.timer

Inhalt:

[Unit]
Description=Startet die naechtliche Home-Sicherung

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=900
AccuracySec=1min

[Install]
WantedBy=timers.target

Der Abschnitt [Install] mit WantedBy=timers.target ist der Grund, warum der Timer nach einem Neustart wieder da ist. Fehlt er, lässt sich die Unit zwar starten, aber nicht dauerhaft aktivieren.

Schritt 3: Einlesen und aktivieren

sudo systemctl daemon-reload
sudo systemctl enable --now backup-home.timer

daemon-reload lädt die Konfiguration des Dienstmanagers neu; laut systemctl(1) werden dabei alle Unit-Dateien neu eingelesen und der gesamte Abhängigkeitsbaum neu aufgebaut. Ohne diesen Schritt kennt systemd eure Datei nicht. enable --now aktiviert die Unit und startet sie in einem Aufwasch.

Beachtet: Aktiviert wird der Timer, nicht der Service. Der Service bleibt inaktiv und wird vom Timer geweckt. Ein häufiger Anfängerfehler ist systemctl enable backup-home.service – damit läuft die Sicherung bei jedem Systemstart genau einmal und danach nie wieder.

Testen lässt sich der Ablauf jederzeit, ohne auf zwei Uhr nachts zu warten:

sudo systemctl start backup-home.service
systemctl status backup-home.service

Damit ist die Grundkonstruktion fertig. Wie die drei beteiligten Units zusammenspielen – die dritte kommt weiter unten dazu – zeigt das folgende Schaubild.

OnCalendar: die Zeitsyntax, die kein Cron-Format ist

Hier liegt die grösste Umgewöhnung. OnCalendar= benutzt nicht die fünf Sternchen aus der Crontab, sondern eine eigene Schreibweise. Die Handbuchseite systemd.time(7) beschreibt das Format als Wochentag Jahr-Monat-Tag Stunde:Minute:Sekunde. Der Wochentag darf fehlen, das Datum ebenso; die Uhrzeit ist der Kern.

Die Operatoren sind schnell erzählt. Ein Sternchen passt auf jeden Wert. Mehrere Werte werden mit Komma aufgezählt. Zwei Punkte bilden einen Bereich, etwa Mon..Fri. Der Schrägstrich bedeutet Wiederholung, also *:0/15 für alle fünfzehn Minuten.

Zusätzlich gibt es Kurzformen, die die Handbuchseite ausdrücklich als Abkürzungen ausweist:

Ein paar praktische Ausdrücke, die die meisten Fälle abdecken:

OnCalendar=*-*-* 02:00:00          # jede Nacht um 02:00
OnCalendar=Mon..Fri *-*-* 07:30    # werktags um 07:30
OnCalendar=Sun *-*-* 04:00:00      # sonntags um 04:00
OnCalendar=*-*-01 03:00:00         # am Ersten jedes Monats um 03:00
OnCalendar=*:0/15                  # alle 15 Minuten
OnCalendar=hourly                  # zur vollen Stunde

Mehrere OnCalendar=-Zeilen in derselben Unit sind erlaubt und ergeben mehrere Auslösezeitpunkte. Eine leere Zuweisung OnCalendar= löscht alle bisherigen Angaben – nützlich in Drop-in-Dateien, verwirrend, wenn es unbeabsichtigt passiert.

Den Ausdruck prüfen, bevor ihr ihn einsetzt

Ihr müsst nicht raten. systemd-analyze hat einen Unterbefehl, der genau dafür da ist. Die Handbuchseite systemd-analyze(1) beschreibt ihn so: „This command will parse and normalize repetitive calendar time events, and will calculate when they elapse next."

systemd-analyze calendar "Mon..Fri *-*-* 07:30"

Die Ausgabe nennt die ursprüngliche Form, die normalisierte Form, den nächsten Auslösezeitpunkt und den Abstand bis dahin. Steht dort ein Datum, das euch überrascht, habt ihr euch vertan – und das vor dem Produktivbetrieb statt danach. Verwandt und ebenso nützlich ist systemd-analyze verify /etc/systemd/system/backup-home.service: Der Befehl meldet unbekannte Abschnitte, fehlende Abhängigkeiten und nicht ausführbare Befehle.

Kalenderausdrücke werden in der lokalen Zeitzone des Systems ausgewertet. Auf einem Server, der auf UTC steht, ist „02:00" also nicht eure Bettzeit – ein Blick auf timedatectl vor dem ersten Timer erspart Verwunderung.

Persistent, RandomizedDelaySec und der Rest der Feineinstellung

Die vier Zeilen aus dem Beispiel sind der Punkt, an dem ein Timer den Cronjob inhaltlich überholt. Alle stammen aus dem Abschnitt [Timer] und sind in systemd.timer(5) beschrieben.

Persistent=true speichert den letzten Auslösezeitpunkt auf der Platte. War das System zum geplanten Termin aus, wird der Job unmittelbar nach dem Hochfahren nachgeholt. Das ist die Funktion, für die es unter Cron ein zweites Programm braucht – anacron –, und auf einem Laptop, der nachts um zwei zugeklappt im Rucksack liegt, ist sie der Unterschied zwischen einer Sicherung und einer Sicherungsabsicht.

RandomizedDelaySec=900 verzögert die Ausführung um eine zufällig gewählte, gleichmässig verteilte Zeitspanne zwischen null und dem angegebenen Wert. Wenn zwanzig Maschinen um Punkt zwei Uhr dieselbe Netzwerkfreigabe ansteuern, verteilt das die Last über eine Viertelstunde. Wollt ihr die Verzögerung stabil statt bei jedem Start neu ausgewürfelt, setzt zusätzlich FixedRandomDelay=true: Der Versatz wird dann aus Maschinen-ID und Unit-Namen abgeleitet und bleibt gleich. Wie stark eure Maschine unter solchen Spitzen tatsächlich leidet, seht ihr mit den Werkzeugen aus Nützliche Linux Konsolen Tools für das Systemmonitoring.

AccuracySec= gibt an, wie genau der Timer treffen soll, und steht laut Handbuch standardmässig auf einer Minute. systemd nutzt diese Toleranz, um Aufwachvorgänge zu bündeln und den Rechner länger schlafen zu lassen. Wer es exakt braucht, setzt AccuracySec=1us – und zahlt das mit Stromverbrauch.

Drei weitere Optionen sind gut zu kennen. OnBootSec= definiert einen Zeitpunkt relativ zum Systemstart, OnUnitActiveSec= einen relativ zur letzten Aktivierung der Zieleinheit. Kombiniert ergibt das „fünf Minuten nach dem Start und danach alle sechs Stunden", ohne jeden Kalender:

[Timer]
OnBootSec=5min
OnUnitActiveSec=6h

Und WakeSystem=true weckt das System aus dem Bereitschaftsbetrieb, wenn der Timer fällig wird. Auf einem Server irrelevant, auf einem Heim-NAS mit Ruhezustand entscheidend.

Soll der Timer eine Unit mit abweichendem Namen starten, gebt sie ausdrücklich an – Unit= ist laut Handbuch „the unit to activate when this timer elapses". Nötig ist das nur, wenn ihr von der Namenskonvention abweicht.

Nachsehen, ob es läuft: list-timers und das Journal

Der wichtigste Befehl im Alltag ist eine Übersicht aller Timer, sortiert nach dem nächsten Auslösezeitpunkt:

systemctl list-timers backup-home.timer

Die Ausgabe sieht so aus:

NEXT                 LEFT      UNIT               ACTIVATES
Do 2026-09-03 02:14  19h left  backup-home.timer  backup-home.service

Die Spalten sind in systemctl(1) beschrieben: NEXT zeigt, wann der Timer das nächste Mal läuft, LEFT wie lange es bis dahin dauert, LAST und PASSED dasselbe rückwärts, UNIT den Namen des Timers und ACTIVATES den Dienst, den er startet. Ohne Argument listet der Befehl alle Timer des Systems auf – der schnellste Weg zu sehen, was auf einer fremden Maschine eigentlich alles nachts passiert. systemctl list-timers --all zeigt zusätzlich die inaktiven.

Die 02:14 in der Ausgabe sind übrigens kein Tippfehler: Das ist RandomizedDelaySec bei der Arbeit.

Was der Job beim letzten Lauf gesagt hat, steht im Journal. Die Option -u filtert laut journalctl(1) auf die Meldungen einer bestimmten Unit:

journalctl -u backup-home.service -n 50 --no-pager
journalctl -u backup-home.service --since "-7d" -p warning
journalctl -u backup-home.service -f

Die erste Zeile zeigt die letzten fünfzig Meldungen, die zweite alle Warnungen und Schlimmeres der vergangenen sieben Tage, die dritte hängt sich live an die Ausgabe und läuft bis Strg+C. Wer tiefer in die Fehlersuche einsteigen will, findet den Rest in unserer Anleitung Linux Problembehebung im systemd.

Nützlich ist ausserdem systemctl cat backup-home.timer: Der Befehl zeigt die Unit so, wie systemd sie tatsächlich sieht, samt allen Drop-ins – und beendet jede Diskussion darüber, welche der drei Kopien nun gilt.

Der eigentliche Gewinn: OnFailure meldet den Fehlschlag

Bis hierhin habt ihr einen Cronjob mit mehr Schreibarbeit. Der Unterschied beginnt jetzt. In systemd.unit(5) steht eine Option, die es unter Cron schlicht nicht gibt: OnFailure= ist „a space-separated list of one or more units that are activated when this unit enters the 'failed' state." Anders gesagt: Geht die Sicherung schief, startet systemd von sich aus eine zweite Unit eurer Wahl. Was diese Unit tut, ist euch überlassen – eine Push-Nachricht, eine Mail, ein Eintrag in ein Monitoring.

Eine Benachrichtigungs-Unit als Vorlage anlegen

Damit ihr die Unit nicht für jeden Job neu schreibt, legt ihr sie als Vorlage an. Der Klammeraffe im Dateinamen macht daraus eine Template-Unit, deren Instanzname später den Namen des fehlgeschlagenen Dienstes trägt.

sudo nano /etc/systemd/system/alarm@.service

[Unit]
Description=Meldet den Fehlschlag von %i per ntfy

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -sS \
  -H "Title: Fehlgeschlagen: %i" \
  -H "Priority: 5" \
  -H "Tags: warning" \
  -d "Auf diesem System ist %i fehlgeschlagen. Details mit: journalctl -u %i -n 50" \
  https://ntfy.sh/EUER-LANGES-ZUFALLSTHEMA

Der Platzhalter %i ist in systemd.unit(5) als Instance name definiert: die Zeichenkette zwischen dem ersten @ und der Endung. Ihr braucht die Unit also genau einmal, egal wie viele Jobs sie später melden soll.

Prüft, ob curl überhaupt installiert ist, und ob der Pfad stimmt:

which curl

Liegt es woanders, tragt den tatsächlichen Pfad ein. ExecStart= verlangt einen absoluten Pfad und findet nichts über die PATH-Variable.

Die Vorlage im Job eintragen

Ergänzt den Abschnitt [Unit] eurer Service-Unit um eine Zeile:

[Unit]
Description=Naechtliche Sicherung des Home-Verzeichnisses
Wants=network-online.target
After=network-online.target
OnFailure=alarm@%n.service

%n ist laut Handbuch der full unit name, hier also backup-home.service. Aus alarm@%n.service wird damit die Unit alarm@backup-home.service.service, und in der Benachrichtigung steht %i für backup-home.service. Das sieht auf den ersten Blick nach einem Tippfehler aus und ist genau richtig so.

sudo systemctl daemon-reload

ntfy einrichten und den Alarm testen

ntfy verschickt Push-Nachrichten über einen einfachen HTTP-Aufruf. Die Projektdokumentation zeigt den Aufbau: Der Nachrichtentext geht per -d an eine URL, deren letzter Bestandteil das Thema ist; Titel, Priorität und Schlagwörter werden über die Kopfzeilen Title, Priority und Tags gesetzt. Priorität 5 ist die höchste von fünf Stufen.

Sicherheitshinweis, und der ist ernst gemeint: Bei ntfy gibt es keine Anmeldung für das blosse Senden und Empfangen. Die Projektdokumentation formuliert das unmissverständlich: „the topic is essentially a password", ihr sollt also etwas wählen, das nicht zu erraten ist. Wer backup als Thema nimmt, teilt seine Ausfallmeldungen mit der halben Welt. Nehmt eine lange Zufallszeichenkette, zum Beispiel erzeugt mit head -c 18 /dev/urandom | base64 | tr -d '/+='. Wer den Dienst nicht in fremden Händen haben will, betreibt ntfy selbst – der Server ist quelloffen und in einem Container schnell aufgesetzt.

Installiert die ntfy-App auf dem Smartphone, abonniert dort euer Thema und löst dann absichtlich einen Fehler aus. Am einfachsten geht das mit einer Wegwerf-Unit:

sudo systemd-run --unit=alarmtest --property=OnFailure=alarm@alarmtest.service /bin/false

/bin/false beendet sich mit einem Fehlerstatus, die Unit geht damit in den Zustand failed, und das Telefon sollte klingeln. Kommt nichts an, prüft zuerst die Benachrichtigungs-Unit selbst:

journalctl -u "alarm@*" -n 30 --no-pager

Wollt ihr statt einer Push-Nachricht eine Mail, ersetzt den curl-Aufruf durch ein Skript, das systemctl status %i und journalctl -u %i -n 50 einsammelt und an sendmail oder msmtp übergibt. Der Mechanismus bleibt derselbe; systemd interessiert sich nicht dafür, was die Unit tut, sondern nur dafür, dass sie startet. Für Erfolgsmeldungen gibt es das Gegenstück OnSuccess=, ausgelöst beim Wechsel in den Zustand inactive.

Timer ohne Root: der Benutzerkontext

Nicht jede Aufgabe gehört ins Systemverzeichnis. Alles, was nur euer Benutzer betrifft – Mails abholen, ein Verzeichnis synchronisieren, eine Datensicherung eures Home – lässt sich im Benutzerkontext ablegen. Die Dateien liegen dann unter ~/.config/systemd/user/, und sämtliche Befehle bekommen --user und kein sudo:

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/backup-home.service
nano ~/.config/systemd/user/backup-home.timer
systemctl --user daemon-reload
systemctl --user enable --now backup-home.timer
systemctl --user list-timers

Zwei Anpassungen sind nötig. Erstens entfällt die Zeile User=, denn der Dienst läuft ohnehin unter euch. Zweitens lautet der Abschnitt [Install] hier WantedBy=default.target statt timers.target.

Und dann kommt die Falle, über die alle einmal stolpern: Benutzer-Units werden standardmässig beendet, sobald ihr euch abmeldet. Auf einem Server, an dem ihr euch nur zum Arbeiten anmeldet, läuft der Timer damit praktisch nie. Abhilfe schafft „Lingering", beschrieben in loginctl(1): „If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts."

sudo loginctl enable-linger mario
loginctl user-status mario

Ersetzt den Benutzernamen. Ab jetzt startet der Benutzermanager beim Systemstart und bleibt nach dem Abmelden bestehen. Rückgängig macht das sudo loginctl disable-linger mario.

Das Journal des Benutzers lest ihr mit journalctl --user -u backup-home.service. Ohne --user sucht ihr an der falschen Stelle und findet nichts – ein Fehler, der schon manchen an seinem Verstand hat zweifeln lassen.

Ein bestehendes Backup umstellen

Der häufigste Anwendungsfall ist die Sicherung. Wer nach unserer Anleitung Linux PC lokal und auf NAS sichern mit Borg arbeitet, hat den Zeitplan bisher in der Oberfläche von Vorta hängen – was voraussetzt, dass die grafische Sitzung läuft. Ein Timer löst dieselbe Aufgabe unabhängig von Anmeldung und Desktop.

Das Vorgehen in vier Schritten: den Ablauf in ein Skript unter /usr/local/bin/ giessen und von Hand ausführen, bis er sauber durchläuft; Service- und Timer-Unit wie oben anlegen; OnFailure= eintragen und den Alarm testen; zuletzt den alten Cron-Eintrag entfernen – crontab -e für den Benutzer, sudo crontab -e für Root, dazu ein Blick in /etc/cron.d/. Wer den alten Eintrag stehen lässt, hat zwei Sicherungen, die sich um dasselbe Verzeichnis streiten.

Ein Wort zum Rückgabewert: systemd erkennt einen Fehlschlag daran, dass der Prozess mit einem Status ungleich null endet. Ein Shell-Skript, das brav exit 0 ans Ende schreibt oder dessen Fehler in einer Pipe verschwinden, meldet niemals einen Fehler – und dann nützt das schönste OnFailure= nichts. Setzt an den Anfang eures Skripts set -euo pipefail, dann bricht es bei einem Fehler ab und gibt ihn weiter.

Wenn etwas nicht klappt

Der Timer taucht in list-timers nicht auf. Entweder fehlt daemon-reload, oder der Timer ist nur gestartet und nicht aktiviert, oder im Abschnitt [Install] fehlt WantedBy=. Prüft mit systemctl is-enabled backup-home.timer.

Der Timer läuft, aber nichts passiert. Wahrscheinlich stimmt die Namenspaarung nicht. Der Timer backup-home.timer sucht backup-home.service; heisst eure Service-Datei anders, tragt Unit= im Abschnitt [Timer] ein. Die Spalte ACTIVATES in list-timers verrät, was er tatsächlich zu starten versucht.

Die Unit geht sofort in failed, Status 203/EXEC. Der Pfad in ExecStart= stimmt nicht oder die Datei ist nicht ausführbar. Absoluter Pfad ist Pflicht, und chmod +x hilft.

Status 217/USER oder 226/NAMESPACE. Der in User= angegebene Benutzer existiert nicht, oder ihm fehlt der Zugriff auf ein Verzeichnis. Prüft den Namen und die Rechte des Zielpfads.

Das Skript läuft von Hand, aber nicht als Unit. Der Klassiker. Units erben eure Shell-Umgebung nicht: kein PATH wie im Terminal, keine Variablen aus .bashrc, kein SSH-Agent, kein DISPLAY. Schreibt absolute Pfade und setzt benötigte Variablen mit Environment= oder EnvironmentFile= in der Unit.

Der Job läuft nachts nicht, weil der Rechner aus war. Dafür ist Persistent=true da. Bei einem Gerät im Ruhezustand hilft zusätzlich WakeSystem=true.

Der Benutzer-Timer läuft nur, solange ihr angemeldet seid. sudo loginctl enable-linger BENUTZER, siehe oben.

Der Alarm kommt nicht an. Prüft mit journalctl -u "alarm@*", ob die Benachrichtigungs-Unit überhaupt gestartet ist. Wurde sie gestartet und curl meldet einen Fehler, fehlt meist die Netzwerkverbindung zum Zeitpunkt des Fehlschlags oder das Thema ist falsch geschrieben. Steht in der Ausgabe gar nichts, wurde OnFailure= nicht ausgelöst – dann endet euer Skript vermutlich mit Status null, obwohl es gescheitert ist.

Fazit: Ein Job, der schweigt, ist kein Job

Der Mehraufwand gegenüber einer Cron-Zeile ist real und überschaubar: zwei Dateien statt einer Zeile, eine ungewohnte Zeitsyntax, ein Befehl zum Neuladen. Dafür bekommt ihr eine geplante Aufgabe, die sich wie jeder andere Dienst abfragen lässt, deren Ausgabe automatisch im Journal steht, die einen verpassten Termin nachholt und die euch anruft, wenn sie gescheitert ist.

Der letzte Punkt ist der einzige, auf den es wirklich ankommt. Eine Sicherung, von der ihr nicht wisst, ob sie läuft, ist keine Sicherung, sondern eine Hoffnung mit Speicherplatzbedarf. Cron kann euch das nicht sagen, weil es dafür nie gebaut wurde. Ein Timer mit OnFailure= kann es, und der Aufwand dafür beträgt sechs Zeilen.

Fangt mit dem einen Job an, dessen Ausfall euch stören würde, und stellt genau den um. Der Rest darf in Ruhe folgen – oder bei Cron bleiben. Es ist keine Glaubensfrage, sondern eine Frage danach, was passieren soll, wenn etwas schiefgeht.

Quellen und weiterführende Links

• systemd.timer(5) – Handbuchseite zu Timer-Units: OnCalendar, Persistent, RandomizedDelaySec, AccuracySec, WakeSystem, Unit
• systemd.time(7) – Kalenderausdrücke, Kurzformen und Zeitspannen
• systemd.unit(5) – OnFailure, OnSuccess und die Platzhalter %i und %n
• systemd.service(5) – Type=oneshot, ExecStart, RemainAfterExit, SuccessExitStatus
• systemd.exec(5) – Logging sowie Standard-Ein- und -Ausgabe von Units
• systemctl(1) – list-timers mit den Spalten NEXT, LEFT, LAST, PASSED, UNIT, ACTIVATES sowie daemon-reload und cat
• systemd-analyze(1) – die Unterbefehle calendar, timespan und verify
• journalctl(1) – die Optionen -u, --since, -p, -f und --user
• loginctl(1) – enable-linger, disable-linger und user-status
• ntfy: Sending messages – Aufbau des Publish-Aufrufs, Kopfzeilen Title, Priority und Tags, Hinweis zur Vertraulichkeit des Themas
• Amazon Linux 2023: Cron und systemd-Timer – Begründung für den Verzicht auf cronie
• Cronjob für Eure Nextcloud erstellen – der klassische Weg mit crontab
• Linux Problembehebung im systemd – Fehler im System mit journalctl eingrenzen
• stdout, stderr und /dev/null – warum Cron-Ausgaben so oft verschwinden
• Linux PC lokal und auf NAS sichern – Borg und Vorta als Praxisbeispiel

The post systemd-Timer statt Cronjob: einrichten und überwachen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Hauptproblem

Falls ihr also beim Aktualisieren eures Systems eine Warnung oder Fehlermeldung wie diese erhaltet:

debsuryorg-archive-keyring (2025.03.11) unstable; urgency=medium

  * The /etc/apt/trusted.gpg.d/debsuryorg-archive.gpg global APT key will
    been removed in the next update of the package.

    The script will try to autodetect whether any APT repository is not
    configured with signed-by= directive and will print warning about the
    installation of this package.

    You need to manually add:

    [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg]

    to your APT sources lists.  See the Debian Wiki for more information:

    https://wiki.debian.org/DebianRepository/UseThirdParty#Sources.list_entry

 -- Ondřej Surý <ondrej@debian.org>  Tue, 11 Mar 2025 14:08:14 +0100

müsst ihr eure APT-Quellen entsprechend anpassen.

Schritt-für-Schritt-Anleitung

Überprüfen, ob das Debsury.org-Repository genutzt wird

Führt folgenden Befehl aus, um zu sehen, ob du das Repository in euren APT-Quellen habt:

grep -r "sury" /etc/apt/sources.list /etc/apt/sources.list.d/

Falls eine Zeile wie diese erscheint:

deb http://packages.sury.org/php/ bookworm main

müsst ihr sie anpassen da diese Zeile nicht mehr dem neuen Standard entspricht.

APT-Quellen aktualisieren

Falls das Repository in einer Datei wie /etc/apt/sources.list.d/php.list steht, bearbeitet diese mit:

sudo nano /etc/apt/sources.list.d/php.list

Ändert die Zeile von:

deb http://packages.sury.org/php/ bookworm main

zu:

deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ bookworm main

Speichert die Datei mit STRG + X, dann Y und ENTER.

GPG-Schlüssel herunterladen und speichern

Falls ihr den neuen Schlüssel noch nicht habt oder unsicher seid, ob er korrekt gespeichert wurde, könnt ihr ihn mit folgendem Befehl herunterladen und am richtigen Ort ablegen:

curl -fsSL https://packages.sury.org/php/apt.gpg | sudo tee /usr/share/keyrings/debsuryorg-archive-keyring.gpg > /dev/null

Dieser Befehl lädt den aktuellen GPG-Schlüssel herunter und speichert ihn in /usr/share/keyrings/.

Paketlisten aktualisieren

Sobald die Datei angepasst und der neue Schlüssel gespeichert wurde, ladet die Paketlisten neu:

sudo apt update

Falls keine Fehlermeldungen mehr erscheinen, ist alles korrekt konfiguriert!

Andere betroffene APT-Repositories identifizieren und korrigieren

Fall ihr weitere betroffene Repositories habt, könnt ihr sie mit folgendem Befehl auflisten:

grep -r "deb " /etc/apt/sources.list /etc/apt/sources.list.d/

Falls Zeilen ohne [signed-by=...] erscheinen, müssen sie entsprechend angepasst werden.

Ihr könnt auch nach alten Schlüsseln suchen:

ls /etc/apt/trusted.gpg.d/

Falls ein anderes Repository betroffen ist (z. B. nginx, crowdsec, apache oder anderes), öffnet die entsprechende Datei:

sudo nano /etc/apt/sources.list.d/nginx.list

Passt die Zeile an:

deb http://nginx.org/packages/debian/ bookworm nginx

zu:

deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/debian/ bookworm nginx

Speichert die Datei und ladet den passenden Schlüssel herunter:

curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg > /dev/null

Danach aktualisiert die Paketlisten:

sudo apt update

Falls weitere Repositories betroffen sind, könnt ihr die gleiche Methode anwenden:

• signed-by hinzufügen
• Den passenden GPG-Schlüssel herunterladen
• apt update ausführen

Wo finde ich die passenden signed-by Schlüssel

Falls ihr nicht wisst, wo ihr die korrekten GPG-Schlüssel für ein bestimmtes Repository findet, gibt es mehrere Möglichkeiten:

1. Offizielle Dokumentation des Repository-Anbieters
   Viele Anbieter listen die korrekten GPG-Schlüssel und signed-by Konfigurationen auf ihrer Website.
2. APT-Fehlermeldungen prüfen
   Falls apt update fehlschlägt, gibt es oft eine Meldung, die dir den fehlenden Schlüssel nennt.
3. Manuell über die Schlüsselserver suchen
   Falls der Schlüssel öffentlich verfügbar ist, könnt ihr ihn mit folgendem Befehl abrufen:gpg --keyserver keyserver.ubuntu.com --recv-keys <Schlüssel-ID> Danach könnt ihr ihn in das Keyring-Verzeichnis verschieben: gpg --export <Schlüssel-ID> | sudo tee /usr/share/keyrings/<repo>-archive-keyring.gpg > /dev/null
4. APT-Quellen selbst inspizieren
   Falls ihr bereits Pakete aus einem Repository installiert habt, könnte sich der passende Schlüssel in einer .gpg-Datei befinden:ls /usr/share/keyrings/

Falls ihr den passenden Schlüssel nicht findet, hilft oft eine Suche mit einer Suchmaschine eurer Wahl mit "GPG key for <Repository-Name>".

Fazit

Diese Änderung ist Teil einer Sicherheitsverbesserung in Debian, um die globale APT-Schlüsselverwaltung abzuschaffen und stattdessen Repository-spezifische Signaturen zu erzwingen. Durch diese Schritte stellt ihr sicher, dass ihr weiterhin Updates von packages.sury.org und anderen Quellen ohne Probleme erhaltet. Weitere Hilfen um dass Linux System korrekt zu updaten, findet ihr hier.

Quellen:

https://wiki.debian.org/DebianRepository/UseThirdParty#Sources.list_entry

The post Fehler mit fehlenden Debian APT-Schlüsseln beheben appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist das Problem

Beim Aktualisieren eines Debian-basierten Systems (z. B. Linux Mint, Ubuntu oder Debian) kann es in seltenen Fällen zu Problemen kommen wenn ein Update durchgeführt wird. Häufige Symptome sind:

• Die Aktuallsierungsverwaltung von Linux Mint spinnt, und updates lassen sich nicht installieren
• Das herunterfahren verlangt plötzlich ein Passwort.
• Fehlermeldungen im Terminal: E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
• Paketmanager (apt, dpkg oder synaptic) bleibt hängen.
• "Dateien werden bereits von einem anderen Prozess verwendet".
• Could not get lock /var/lib/dpkg/lock oder Could not open lock file /var/lib/apt/lists/lock.

In diesem Tutorial gehen wir Schritt für Schritt durch, wie man diese Probleme lösen kann.

Prüfen, ob ein anderer Prozess läuft

Zuerst ist es wichtig zu sagen, dass ihr bei einem Update-Problem das System am besten nicht neustartet, bis ihr das Problem behoben habt, ansonsten kann es in selten Fällen dazu kommen, dass das System nicht mehr hochfährt, wenn ein extrem wichtiges Paket beim Updaten beschädigt worden ist.

Um das Problem zu beheben überprüfen wir, ob gerade ein Update oder Installationsprogramm läuft. Auf Linux Mint geht das zum Beispiel bequem über die Systemüberwachung. Öffnet diese über die Suche, und sucht oben rechts mit dem Lupensymbol nach apt.

Falls ein Update unterbrochen wurde oder Pakete beschädigt sind, kommt meisstens bei einem erneuten Update Befehl ein Fehler, dieser schaut dann auf dem Terminal meisst so aus:

Über das Terminal könnt ihr auch nach einem Apt Prozess suchen:

ps aux | grep -E apt

Falls ein Prozess wie apt-get aktiv ist, müssen wir zu allerst versuchen, ihn mit einem kill Befehl zu beenden:

sudo killall apt apt-get dpkg

Falls das nicht hilft, könnt ihr den Prozess manuell mit der PID (Prozess-ID) beenden:

sudo kill -9 <PID>

Ersetze <PID> mit der jeweiligen Prozess-ID, die ihr vorher mit der Systemüberwachung oder im Terminal via ps aux herausgefunden habt. In meinem Fall wäre das die ID 7400

Solltet ihr mit dem killen des apt Prozess kein Erfolg haben, springt zu Punkt 3, ansonsten, lasst ihr Punkt 3 unten aus!

2. Paketverwaltung reparieren

Sollte Apt erfolgreich beendet worden sein, müssen wir als nächstes die Fehler beheben. Wichtig ist, euer System jetzt nicht herunterzufahren, und später zu starten. Das kann in selten Fällen dazu führen, dass das System nicht wieder hochfährt. Um Update-Fehler zu beheben, müssen wir apt/dpkg und entsprechende Pakete rekonfigurieren. Das geht automatisch über einen Befehl:

sudo dpkg --configure -a

Dies rekonfiguriert alle abgebrochenen updates. Ist zum Beispiel das Update von Grub fehlgeschlagen, musst es ebenfalls frisch konfiguriert werden. Bitte nehmt hier dann unbedingt eure Platte, auf dem euer System läuft:

Hier muss die System Platte, also /dev/sdx ausgewählt werden, und auf keinen Fall Partitionen mit den Nummern da hinter, zum Beispiel /dev/sdx1.

In den meissten Fällen ist aber ein manuelles Eingreifen nicht notwendig.

Falls andere Pakete noch nicht vollständig installiert wurden:

sudo apt-get install -f

3. Locks entfernen (optional)

Falls dpkg oder apt eine Sperrdatei (lock-File) erstellt hat, die nicht automatisch entfernt wurde, kann dies Updates blockieren.

Überprüfe, ob folgende Sperrdateien existieren:

ls -l /var/lib/dpkg/lock
ls -l /var/lib/dpkg/lock-frontend
ls -l /var/lib/apt/lists/lock
ls -l /var/cache/apt/archives/lock

Falls eine oder mehrere existieren und kein Prozess mehr läuft, könnt ihr sie manuell löschen:

sudo rm -f /var/lib/dpkg/lock
sudo rm -f /var/lib/dpkg/lock-frontend
sudo rm -f /var/lib/apt/lists/lock
sudo rm -f /var/cache/apt/archives/lock

Danach könnt ihr das Paketmanagement wieder korrekt initialisieren:

sudo dpkg --configure -a

4. Cache leeren und Paketquellen neu einlesen

Falls das Problem weiterhin besteht, kann es helfen, den Paket-Cache zu leeren und die Paketquellen neu zu laden:

sudo apt-get clean
sudo apt-get autoclean
sudo apt-get update

Falls update Probleme macht, kann ein erneutes Generieren der Paketquellen helfen:

sudo rm -rf /var/lib/apt/lists/*
sudo apt-get update

5. Beschädigte Pakete entfernen

Falls noch immer Fehler auftreten, kann es sein, dass ein beschädigtes oder unvollständiges Paket vorhanden ist.

Liste beschädigte Pakete auf:

dpkg -l | grep -v ^ii

Falls ihr ein fehlerhaftes Paket findet, könnt du es mit folgendem Befehl entfernen:

sudo apt-get remove --purge <Paketname>

Falls remove nicht funktioniert, könnt ihr es manuell aus dpkg entfernen:

sudo dpkg --remove --force-remove-reinstreq <Paketname>

Danach:

sudo apt-get install -f

6. Neustart und erneuter Test

Nach den oben genannten Schritten kann ein Neustart helfen:

sudo reboot

Danach erneut testen:

sudo apt update && sudo apt upgrade

Falls immer noch Probleme bestehen, könnte es an defekten Paketen oder einer beschädigten sources.list liegen.

Fazit

Mit diesen Methoden könnt ihr die meisten Probleme mit apt und dpkg auf Debian-basierten Systemen beheben. Falls sich apt oder dpkg aufhängt, reicht es oft schon, den laufenden Prozess zu beenden und dpkg --configure -a auszuführen.

Falls ihr nach diesen Schritten immer noch Probleme habt, könnte es ein tiefergehendes Problem mit den Paketquellen oder einer fehlerhaften Systemkonfiguration sein. In diesem Fall lohnt sich ein Blick in die /var/log/apt/-Logs, um den Fehler zu finden. Im schlimmsten Fall setzt ihr auf ein wenige Tage altes Timeshift Backup.

Viel Erfolg! 🚀

The post Update Fehler unter Debian basierten Systemen beheben appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.