01
Zeitbasis festlegen
Der Kalender beginnt mit daily um Mitternacht; relativ beginnt der erste Lauf nach 5min. OnUnitActiveSec zählt ab Dienstaktivierung, nicht nach deren Ende.
- Die beiden Modi werden hier nicht gemischt.
Cron & Scheduling
systemd Timer erstellen · Kalenderzeit und Bootintervall trennen
Erstellen Sie eine .timer-Unit für einen vorhandenen Dienst und prüfen Sie sie auf dem Zielsystem.
systemd Timer erstellen
Auslöser eingeben
Timer-Konfiguration und Prüfung
Die Eingabe wird in diesem Browser verarbeitet und nicht an einen Server gesendet.
Optionen
Geben Sie den Basisnamen eines vorhandenen Dienstes ein.
Ein Backup um 9 Uhr an Werktagen ist etwas anderes als ein Start fünf Minuten nach dem Booten. systemd Timer erstellen trennt die OnCalendar-Syntax vom monotonen Timer, damit ein Cron-Ausdruck nicht als Kalenderregel ausgegeben wird.
Wenn Sie mit systemd Timer erstellen arbeiten, erhalten Sie eine .timer-Unit ohne erfundene .service-Datei. Die Ausgabe enthält die Prüfbefehle, aber die tatsächlichen nächsten Ausführungen ermittelt systemd auf dem Zielrechner.
Warum systemd Timer erstellen nutzen?
Die Zeitbasis bleibt beim Kopieren der Unit sichtbar.
Zwei Auslöser, zwei Zeitbasen
OnCalendar bezieht sich auf die Uhrzeit. OnBootSec zählt vom Booten, OnUnitActiveSec von der letzten Aktivierung des Dienstes. Diese Unterscheidung verhindert falsche Aussagen über stündliche Läufe.
Prüfung am richtigen Ort
Der Browser erkennt nur einfache Datumsformen und Abkürzungen. Für Listen, Schritte oder Zeitzonen markiert er die Regel als ungeprüft und gibt systemd-analyze calendar für Linux aus.
Drei Prüfungen vor dem Aktivieren
02
Vorhandenen Dienst benennen
Geben Sie nur den Basisnamen ohne .timer oder .service ein. Beispiel, Vorlage und Leeren zeigen erst eine Vorschau und lassen sich einmal rückgängig machen.
- Ohne Namen gibt es keine exportierbare Unit.
03
Auf Linux gegenprüfen
Einfache Ausdrücke werden lokal auf Form und Werte geprüft. Für alle OnCalendar-Erweiterungen starten Sie systemd-analyze calendar, danach verify und status.
- Bei ausgeschalteter Automatik startet Ctrl/Cmd + Enter die Erstellung.
Bausteine der erzeugten Unit
Kalendertermin
daily, hourly und Werktage um 9 Uhr stehen bereit; eine einzelne OnCalendar-Regel kann frei eingegeben werden. Persistent holt versäumte Kalenderereignisse nach.
Relativer Start
OnBootSec legt den ersten Lauf nach dem Booten fest; optional zählt OnUnitActiveSec ab der letzten Dienstaktivierung weiter.
Eigenständige .timer-Datei
Unit= verweist auf den gleichnamigen Dienst. Optionaler Zufallsaufschub und WantedBy=timers.target werden nur bei Bedarf beziehungsweise als Installationsziel ergänzt.
Was die Unit nicht zusichert
- Der Dienst muss existieren
- ExecStart, User und WorkingDirectory gehören zur .service-Datei, die diese Seite nicht erzeugt. Prüfen Sie den Dienst vor dem Aktivieren.
- Nur ein Syntaxteil wird lokal geprüft
- Listen, Schrittweiten, Monatsende und Zeitzonen bleiben ungeprüft. Der systemd-analyze des Zielsystems ist für ihre Bedeutung maßgeblich.
- Cron ist kein OnCalendar
- Fünf Cron-Felder werden abgewiesen. Persistent wirkt nur bei Kalendertimern; das Standard-AccuracySec erlaubt ein Zeitfenster von einer Minute.
- Ein System-Timer pro Ergebnis
- OnCalendar wird nicht mit monotonen Auslösern gemischt; das Kalenderfeld akzeptiert nur eine Zeile. Benutzer-Units und OnStartupSec werden nicht abgebildet.
- Befehle werden nicht ausgeführt
- Die Seite führt kein systemctl aus, schreibt keine Unit auf den Zielrechner und verspricht keinen exakten nächsten Lauf. Prüfen Sie den gespeicherten Timer und den vorhandenen Dienst auf dem Linux-System.
Fragen zu systemd Timer erstellen
Warum braucht ein Auftrag sowohl .timer als auch .service?
Die Timer-Unit bestimmt den Zeitpunkt; der Dienst enthält Befehl und Umgebung. Hier wird nur die Timer-Unit erstellt.
Was bewirkt Persistent=true genau?
Ein verpasster Kalendertermin kann beim erneuten Aktivieren nachgeholt werden. Für OnBootSec erzeugt es keinen Wiederholungszyklus.
Wie prüfe ich einen OnCalendar-Ausdruck?
Führen Sie den ausgegebenen Befehl systemd-analyze calendar auf dem Zielsystem aus und lesen Sie die normalisierte Regel und die nächsten Termine.
Warum funktioniert der Befehl im Terminal, aber nicht im Timer?
Ein systemd-Dienst hat eine andere Umgebung als die interaktive Shell. Prüfen Sie absolute Pfade, Umgebungsvariablen und das Journal.
Warum startet der Dienst vor dem geplanten Kalendertermin?
Ein bereits fälliges OnBootSec oder ein durch Persistent nachgeholter Termin kann den sofortigen Start erklären.
Ein unerwarteter Termin?
Jetzt systemd Timer erstellen
Geben Sie den Dienstnamen ein, erzeugen Sie die Unit und prüfen Sie sie auf Linux.
Die Unit entsteht im Browser und wird nicht hochgeladen.