Startseite
Systemd Timer Generator
systemd v240+ Standard•OnCalendar, OnBootSec, Persistent & Jitter

Linux Systemd (.timer & .service) Unit Generator

Erstellen Sie produktionsreife systemd-Timer-Units und zugehörige Oneshot-Services mit OnCalendar-Planung, OnBootSec-Intervallen, Persistent-Ausführung und zufälligen Verzögerungen.

Voreinstellungen:
ZeitplanCalendar trigger active: "*-*-* 02:30:00" • Catch-up enabled (executes immediately upon boot if system was down when scheduled) • Adds random jitter up to 15m to prevent cluster load spikes
Eingabe
Unit-Benennung & Identifikation/etc/systemd/system/
.timer
Auslösemechanismus
Ausführung des BegleitdienstesType=oneshot
Sandboxing & SicherheitshärtungLinux-Namespaces
#!/usr/bin/env bash
# ==============================================================================
# Linux Systemd Unit Installer: db-backup.timer & db-backup.service
# Auto-generated by ToolsAA (https://toolsaa.com)
# ==============================================================================
set -euo pipefail

echo "=========================================================="
echo " [ToolsAA] Deploying Systemd Timer: db-backup"
echo "=========================================================="

if [ "$EUID" -ne 0 ]; then
  echo "[-] Error: Root privileges required. Re-run with: sudo bash $0" >&2
  exit 1
fi

TARGET_DIR="/etc/systemd/system"

# 1. Write companion service unit
echo "[+] Installing ${TARGET_DIR}/db-backup.service..."
cat << 'EOF' > "${TARGET_DIR}/db-backup.service"
[Unit]
Description=Daily Off-Peak Database Dump and Sync
Documentation=man:systemd.service(5)
After=network.target network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh --all --compress --dest /var/backups
WorkingDirectory=/var/backups
User=postgres
Group=postgres
TimeoutStartSec=1h
Nice=10

# Hardening & Sandboxing
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=true
StandardOutput=journal
StandardError=journal
SyslogIdentifier=db-backup
EOF

# 2. Write timer unit
echo "[+] Installing ${TARGET_DIR}/db-backup.timer..."
cat << 'EOF' > "${TARGET_DIR}/db-backup.timer"
[Unit]
Description=Timer for Daily Off-Peak Database Dump and Sync
Documentation=man:systemd.timer(5)

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=15m
AccuracySec=1m
Unit=db-backup.service

[Install]
WantedBy=timers.target
EOF

# 3. Apply secure unit file permissions (644)
chmod 644 "${TARGET_DIR}/db-backup.service" "${TARGET_DIR}/db-backup.timer"

# 4. Reload systemd daemon
echo "[+] Reloading systemd manager configuration..."
systemctl daemon-reload

# 5. Enable and immediately activate the timer
echo "[+] Enabling and starting db-backup.timer..."
systemctl enable --now "db-backup.timer"

# 6. Verify timer status and list upcoming triggers
echo ""
echo "=========================================================="
echo " [✓] Deployment Complete! Next Scheduled Executions:"
echo "=========================================================="
systemctl list-timers --all | grep -E "db-backup|NEXT" || true
echo ""
echo "To test service execution immediately:"
echo "  sudo systemctl start db-backup.service"
echo "To view execution logs:"
echo "  journalctl -u db-backup.service -f"
Auslöser-Mechanismus
calendar Trigger

*-*-* 02:30:00

Befehl ausführen
Type=oneshot

User: postgres • Nice (Priority): 10

Sandbox & Jitter
Vollständige Sandbox

Persistent (Nachholen bei Start): Ja • Jitter: 15m

Zero-Knowledge Lokale Ausführung

Alle Datenverarbeitungen, Parsen und Generierungen laufen streng im lokalen Browserspeicher ab. Keine externen Server-Uploads.

Sub-Millisekunden AST-Engine

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technische Referenz & Architektur-Leitfaden

Tägliche Off-Peak-Datenbanksicherung — Referenz-Leitfaden

Erstellen Sie produktionsreife systemd-Timer-Units und zugehörige Oneshot-Services mit OnCalendar-Planung, OnBootSec-Intervallen, Persistent-Ausführung und zufälligen Verzögerungen.

Wichtige Parameter & Steuerelemente

unitNamestring

Basisname für das Timer- und Companion-Service-Paar (erzeugt <unitName>.timer und <unitName>.service).

Standard: backup-job
onCalendarstring

Echtzeit-Kalenderspezifikation basierend auf der systemd.time(7)-Syntax für wiederkehrende Zeitpläne.

Standard: *-*-* 03:00:00
onBootSecstring

Monotoner Zeitversatz nach dem Systemstart vor dem ersten Auslösen des Timers.

Standard: 15min
persistentboolean

Speichert den letzten Ausführungszeitstempel auf der Festplatte, damit verpasste Läufe nach Systemneustarts sofort nachgeholt werden.

Standard: true
randomizedDelaySecstring

Zufälliges Zeitfenster (Jitter), um Lastspitzen durch gleichzeitige Ausführung auf verteilten Servern zu vermeiden.

Standard: 10m
execStartstring

Absoluter Dateipfad und Befehlsparameter, die von der Companion-Service-Unit ausgeführt werden.

Standard: /usr/local/bin/backup.sh

Profi-Tipps & Best Practices

Führen Sie vor dem Deployment

Führen Sie vor dem Deployment systemd-analyze calendar '<ausdruck>' im Terminal aus, um normalisierte Zeitstempel und die nächsten geplanten Ausführungszeitpunkte zu überprüfen.

Wenn <name>.timer und <name>.service

Wenn <name>.timer und <name>.service denselben Basisnamen tragen, verknüpft systemd diese automatisch, ohne dass eine explizite Unit=-Direktive im [Timer]-Abschnitt erforderlich ist.

Verwenden Sie in der

Verwenden Sie in der Companion-Service-Unit Type=oneshot zusammen mit RemainAfterExit=no, damit der Prozess nach Abschluss sauber beendet wird und künftige Timer-Trigger konfliktfrei starten.

Mit systemctl list-timers --all

Mit systemctl list-timers --all behalten Sie den Überblick über alle aktiven Timer, die verbleibende Wartezeit sowie den Status des letzten Laufs.

Häufige Fallstricke & Fehlerbehebung

Timer ist aktiv, aber der zugehörige Service wird nicht ausgelöst

Führen Sie nach Änderungen an Unit-Dateien in /etc/systemd/system/ stets sudo systemctl daemon-reload aus. Prüfen Sie, ob in ExecStart ein absoluter Pfad angegeben ist, und kontrollieren Sie Fehlermeldungen mit journalctl -u <name>.service -e.

Wartungsaufgaben wurden während des Serverstillstands übersprungen und nicht nachgeholt

Aktivieren Sie Persistent=true im [Timer]-Abschnitt. Systemd speichert Zeitstempel unter /var/lib/systemd/timers/stamp-<name>.timer. Ohne diesen Parameter verfallen verpasste Ausführungen ersatzlos.

Timer löst in einer unendlichen Sekundenschleife ununterbrochen aus

Verwenden Sie keine offenen Sekunden-Platzhalter wie *-*-* *:*:*. Definieren Sie eine feste Sekunde wie *-*-* 02:00:00 oder Intervallschritte wie *:0/15, damit der Job nur einmal pro Intervall feuert.

Häufig gestellte Fragen (FAQ)

Welche Vorteile bieten systemd-Timer gegenüber klassischen Cronjobs?▼

Systemd-Timer bieten eine nahtlose Integration in journalctl für zentrales Logging, Ressourcendrosselung via cgroups, Mikrosekunden-Präzision, Abhängigkeitssteuerung (z. B. After=network.target) und ersetzen Anacron durch die Persistent-Funktion.

An welchem Speicherort müssen die .timer- und .service-Dateien abgelegt werden?▼

Systemweite Units gehören nach /etc/systemd/system/. Für unprivilegierte Benutzer-Timer legen Sie die Dateien unter ~/.config/systemd/user/ ab und verwalten sie mit systemctl --user.

Wie wird der neue Timer scharfgeschaltet und gestartet?▼

Führen Sie sudo systemctl daemon-reload aus und aktivieren Sie den Timer anschließend mit sudo systemctl enable --now <name>.timer. Den Status prüfen Sie mit systemctl status <name>.timer.

Kann ein einzelner Timer mehrere Services gleichzeitig triggern?▼

Standardmäßig steuert ein Timer genau eine Service-Unit an. Um mehrere Aufgaben parallel oder sequentiell auszulösen, binden Sie eine systemd-Target-Unit ein oder rufen ein koordinierendes Shell-Skript auf.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →
TypeScript (tsconfig.json) Konfigurations-Generator Entwickler-HandbuchEntwickler

Erstellen Sie moderne, robuste tsconfig.json-Konfigurationen für Next.js, Node.js, Vite oder Bibliotheken mit Strict Mode, Pfad-Aliasen und optimaler Modulauflösung.

Werkzeug öffnen→
Entwicklerhandbuch für den JSON zu ClickHouse CREATE TABLE DDL GeneratorEntwickler

Konvertieren Sie JSON-Dokumente in ClickHouse SQL DDL mit MergeTree-Engine, UInt/Int/Float/String/DateTime-Typen sowie Array/Nested-Spaltenzuordnungen.

Werkzeug öffnen→
JSON zu Google BigQuery Tabellenschema GeneratorEntwickler

Analysieren und konvertieren Sie JSON-Objekte in Google Cloud BigQuery-Tabellenschema-JSON mit RECORD-Modus, STRING-, INTEGER-, NUMERIC- und TIMESTAMP-Feldern.

Werkzeug öffnen→
Entwicklerhandbuch: JSON zu Snowflake CREATE TABLE DDL GeneratorEntwickler

Konvertieren Sie JSON-Nutzdaten und -Schemas in produktionsreife Snowflake SQL CREATE TABLE-Anweisungen mit optimierten Datentypen wie VARIANT, VARCHAR, NUMBER, BOOLEAN und TIMESTAMP_NTZ.

Werkzeug öffnen→
JSON / YAML zu Terraform HCL Variablen & Locals GeneratorEntwickler

Konvertieren Sie JSON- und YAML-Payloads in Terraform HCL-Typbeschränkungen (type = object({...})), Standardwerte, locals-Blöcke und terraform.tfvars-Definitionen.

Werkzeug öffnen→
OpenAPI / Swagger zu GraphQL SDL Schema KonverterEntwickler

Konvertieren Sie OpenAPI 3.0/3.1 und Swagger 2.0 REST-Endpunkte, Request-Bodys und JSON-Schemas in GraphQL-SDL-Typen, Queries, Mutations und Input-Definitionen.

Werkzeug öffnen→