Cron
Klassischer Unix-Auftragsplaner
Systemd Timer
Moderniser dienstbasierter Scheduler
Umfassender Vergleich zwischen Cron- und Systemd-Timer-Schedulern. Erfahren Sie, wann Sie welchen verwenden, ihre Funktionen, Vor- und Nachteile und wie Sie zwischen ihnen migrieren.
Quick Comparison
| Feature | ⏰ Cron | ⚙️ Systemd Timer |
|---|---|---|
| Planungsstil | Nur zeitbasiert | Zeit- oder ereignisbasiert |
| Granularität | Minuten | Mikrosekunden |
| Abhängigkeiten | Keine | Volle Unterstützung |
| Protokollierung | Basis-E-Mail/Log | journald-Integration |
| Pro-Benutzer-Jobs | Ja | Ja |
| Monotone Timer | Nein | Ja |
| Ressourcen-Tracking | Nein | Ja (cgroups) |
| Plattformabdeckung | Universell | Nur systemd |
| Lernkurve | Einfach | Mäßig |
| Container-freundlich | Ausgezeichnet | Schlecht |
Kernfunktionen
Planungsgenauigkeit
Cron: Minutenebene
Systemd Timer: Mikrosekundenebene
💡 Why: Systemd-Timer unterstützen feinere Planung mit Mikrosekunden-Genauigkeit, während cron nur Minutengenauigkeit unterstützt.
Echtzeit-Planung
Cron: ✅ Volle Unterstützung
Systemd Timer: ✅ Volle Unterstützung
💡 Why: Beide unterstützen traditionelle zeitbasierte Planung (z.B. "jeden Tag um 3 Uhr").
Monotone Timer
Cron: ❌ Nicht unterstützt
Systemd Timer: ✅ Volle Unterstützung
💡 Why: Systemd unterstützt Timer basierend auf Zeit seit Start oder anderen Ereignissen, was cron nicht kann.
Ereignisauslöser
Cron: ❌ Keine
Systemd Timer: ✅ Mehrere Ereignisse
💡 Why: Systemd kann bei Hardware-Ereignissen, Pfadänderungen und anderen Systemereignissen auslösen.
Konfiguration & Verwaltung
Konfigurationsformat
Cron: Crontab (einfach)
Systemd Timer: INI-Stil Einheiten
💡 Why: Cron verwendet ein einfaches, gut bekanntes crontab-Format. Systemd verwendet komplexere Einheitsdateien.
Pro-Benutzer-Planung
Cron: ✅ Unterstützt
Systemd Timer: ✅ Unterstützt
💡 Why: Beide unterstützen pro-Benutzer-Planung (Benutzer-crontabs vs systemd-Benutzereinheiten).
Umgebungsvariablen
Cron: Eingeschränkt
Systemd Timer: Volle Unterstützung
💡 Why: Systemd bietet bessere Umgebungsvariablen-Verwaltung durch Dienstdateien.
Abhängigkeitsverwaltung
Cron: ❌ Keine
Systemd Timer: ✅ Volle Unterstützung
💡 Why: Systemd-Timer können von Diensten, Sockets, Targets und anderen Einheiten abhängen.
Protokollierung & Überwachung
Eingebaute Protokollierung
Cron: E-Mail/Logs
Systemd Timer: journald
💡 Why: Systemd integriert eng mit journald für strukturierte, durchsuchbare Protokolle.
Job-Verlauf
Cron: Eingeschränkt
Systemd Timer: ✅ Verfolgt
💡 Why: Systemd behält detaillierte Historie von Timer-Auslösungen und Dienst-Ergebnissen.
Ressourcenüberwachung
Cron: ❌ Keine
Systemd Timer: ✅ cgroups
💡 Why: Systemd verfolgt die Ressourcennutzung über cgroups für jeden Dienst.
Fehlerbehandlung
Cron: Nur E-Mail
Systemd Timer: Mehrere Optionen
💡 Why: Systemd unterstützt on-failure-Auslöser, Neustart-Richtlinien und abhängigkeitsbasierte Reaktionen.
Leistung & Ressourcen
Speichernutzung
Cron: ~1-2 MB
Systemd Timer: ~5-10 MB
💡 Why: Cron-Daemon verwendet minimalen Speicher. Systemd läuft bereits, Timer fügen vernachlässigbaren Overhead hinzu.
Startzeit
Cron: Schnell
Systemd Timer: Sofort
💡 Why: Systemd ist Teil von init, läuft bereits beim Boot.
Skalierbarkeit
Cron: Gut
Systemd Timer: Ausgezeichnet
💡 Why: Systemd verarbeitet tausende Einheiten effizienter mit modernem Prozessmanagement.
Systemintegration
Cron: Eigenständig
Systemd Timer: Integriert
💡 Why: Systemd-Timer sind nativ für systemd-basierte Systeme.
Plattform & Kompatibilität
Linux-Unterstützung
Cron: ✅ Universell
Systemd Timer: Nur systemd
💡 Why: Cron funktioniert auf allen Linux-Systemen. Systemd-Timer nur auf systemd-basierten Distributionen.
Unix/BSD-Unterstützung
Cron: ✅ Ja
Systemd Timer: ❌ Nein
💡 Why: Cron ist auf fast allen unixoiden Systemen verfügbar.
macOS-Unterstützung
Cron: ✅ launchd/cron
Systemd Timer: ❌ Nein
💡 Why: macOS verwendet launchd (nicht systemd), aber cron ist verfügbar.
Container-Unterstützung
Cron: ✅ Einfach
Systemd Timer: Komplex
💡 Why: Cron funktioniert in minimalen Containern. Systemd benötigt volles systemd-init.
Practical Examples
Einfache tägliche Sicherung
Cron
# Sicherung um 2 Uhr morgens
0 2 * * * /root/backup.sh
Cron ist einfacher für diese einfache Aufgabe. Systemd benötigt zwei Dateien (Timer + Service), bietet aber Persistenz über Neustarts hinweg.
15 Minuten nach Boot ausführen
Cron
# Nicht einfach unterstützt
# Würde @reboot mit sleep benötigen
Systemd unterstützt Boot-verzögerte Ausführung nativ. Cron würde komplexe Workarounds erfordern.
Ausführen, wenn Netzwerk oben ist
Cron
# Nicht unterstützt
Systemd kann auf bestimmte Systemzustände warten. Cron hat keine Abhängigkeitswahrnehmung.
Migration Guide
Cron → Systemd Timer
- → Erstellen Sie sowohl .timer- als auch .service-Dateien (cron-Eintrag = Timer + Service kombiniert)
- → Verwenden Sie OnCalendar für zeitbasierte Planung (konvertiert cron-Ausdrücke)
- → Verwenden Sie Persistent=true, um Jobs auszuführen, die während Ausfallzeiten verpasst wurden
- → Verschieben Sie Umgebungsvariablen von crontab zu [Service] Environment=
- → Ersetzen Sie E-Mail-Ausgabe durch journald-Protokollierung
- → Konvertieren Sie Benutzer-crontabs zu systemd-Benutzereinheiten (~/.config/systemd/user/)
- → Verwenden Sie systemctl list-timers, um alle Timer anzuzeigen (ähnlich wie crontab -l)
Cron → Systemd Timer
- → Verlieren Sie Abhängigkeitsverwaltung - Skript muss Abhängigkeiten behandeln
- → Konvertieren Sie OnCalendar zu cron-Ausdrücken (Minute Stunde Tag Monat Wochentag)
- → Ersetzen Sie monotone Timer (OnBootSec) durch @reboot und sleep
- → Entfernen Sie ereignisbasierte Auslöser (cron ist zeit-only)
- → Umgebungsvariablen gehen in crontab oder Skript
- → Protokollierung muss manuell gehandhabt werden (syslog, benutzerdefinierte Dateien)
- → Keine eingebaute Persistenz - letzten Lauf manuell in Skripten verfolgen
Frequently Asked Questions
Welches sollte ich für einen neuen Linux-Server wählen? ▼
Können cron und systemd-Timer koexistieren? ▼
Wie zeige ich alle geplanten Aufgaben wie crontab -l an? ▼
Funktionieren systemd-Timer in Docker-Containern? ▼
Wird cron deprecated? ▼
Können systemd-Timer bei Versagen E-Mails senden wie cron? ▼
Welches verwendet weniger Systemressourcen? ▼
Wie plane ich einen Job, der alle 10 Sekunden läuft? ▼
Verdict: Keiner - Wahl basierend auf Anforderungen
Sowohl cron als auch systemd-Timer sind leistungsstarke Job-Scheduler, die unterschiedliche Bedürfnisse erfüllen. **Cron bleibt die universelle Wahl** für einfache, portable Planung auf allen unixoiden Systemen. **Systemd-Timer glänzen** auf modernen Linux-Distributionen, die komplexe Abhängigkeiten, Ereignisauslöser und integrierte Protokollierung erfordern.
Recommendation
Verwenden Sie **cron** für einfache periodische Aufgaben, Cross-Plattform-Kompatibilität, Legacy-Systeme und Container. Verwenden Sie **systemd-Timer** für moderne Linux-Server, Service-Orchestrierung, ereignisgesteuerte Planung und wenn Sie enge Integration mit Systemdiensten benötigen.