Verschieben Sie eine crontab-Zeile auf einen systemd-Timer.

Er nimmt eine einzelne crontab-Zeile — die fünf Zeitfelder plus den Befehl — und erzeugt ein äquivalentes systemd-Setup: eine .timer-Unit mit einem OnCalendar=-Ausdruck, der Ihren Zeitplan abbildet, und eine .service-Unit, die Ihren Befehl ausführt. Außerdem listet er Migrationshinweise auf, die alles kennzeichnen, was systemd anders handhabt, etwa das implizite Arbeitsverzeichnis oder die Umgebung. Alles wird in Ihrem Browser berechnet.

Nein. Der Converter läuft zu 100 % clientseitig. Ihre cron-Zeile und Ihr Befehl werden in Ihrem Browser-Tab geparst und übersetzt — nichts wird auf einen Server hochgeladen, und es gibt kein Konto und keine Anmeldung. Sie können bedenkenlos interne Befehle und Pfade einfügen.

Ein Satz von crontab-Feldern wird in die OnCalendar=-Kalendersyntax von systemd umgeschrieben — zum Beispiel wird aus „0 3 * * *“ der Ausdruck „*-*-* 03:00:00“ (täglich um 03:00). Listen, Bereiche und Schrittwerte werden auf ihre OnCalendar-Entsprechungen abgebildet, und gängige @macros wie @daily und @hourly werden auf ihre kanonischen Timer-Formen abgebildet. Nach der Installation des Timers können Sie die nächsten Läufe mit „systemctl list-timers“ bestätigen.

Timer bieten Ihnen strukturiertes Logging über das Journal (journalctl -u your.service), Abhängigkeitsreihenfolge, Ressourcenlimits, automatische Wiederholungen sowie genaue im Vergleich zu monotoner Planung, dazu Persistent=true, damit ein verpasster Lauf beim nächsten Boot ausgelöst werden kann. Sie sind die native Planungsprimitive auf modernen systemd-Linux-Distributionen, auf denen der benutzereigene crond oft nicht einmal installiert ist.

Einige cron-Verhaltensweisen haben kein direktes OnCalendar=-Äquivalent und erscheinen stattdessen als Migrationshinweise — nicht standardmäßige oder herstellerspezifische cron-Erweiterungen, MAILTO E-Mail-bei-Ausgabe (verwenden Sie journald oder einen OnFailure=-Handler) und zeilenweise Umgebungszuweisungen (verschieben Sie diese nach Environment= oder in eine EnvironmentFile= in der .service). Der Converter kennzeichnet diese, damit sich nichts stillschweigend in seiner Bedeutung ändert.

Nein. Dies ist ein unabhängiges Community-Dienstprogramm und steht in keiner Verbindung zum systemd-Projekt oder einer cron-Implementierung und wird von diesen nicht unterstützt. Es bildet die Standardformate von crontab und systemd-Units zur Wiedererkennung nach und benennt sie nur, um zu beschreiben, was es konvertiert.

@reboot hat kein OnCalendar=-Äquivalent und wird im [Timer]-Abschnitt auf OnBootSec=1min abgebildet, sodass der Job einmal kurz nach jedem Boot ausgelöst wird. @hourly expandiert zu OnCalendar=*-*-* *:00:00, @daily zu OnCalendar=*-*-* 00:00:00, @weekly zu OnCalendar=Sun *-*-* 00:00:00, @monthly zu OnCalendar=*-*-01 00:00:00 und @yearly zu OnCalendar=*-01-01 00:00:00. Der Converter behandelt all dies automatisch und weist auf den Sonderfall @reboot hin.

Fügen Sie dem [Timer]-Abschnitt neben Ihrer OnCalendar=-Zeile Persistent=true hinzu. systemd hält den Zeitpunkt der letzten Auslösung auf der Festplatte fest und führt den Job, falls der geplante Zeitpunkt verstrichen ist, während die Maschine aus war, beim nächsten Boot sofort aus. Der Converter nimmt Persistent=true immer in die erzeugte .timer-Unit auf, sodass dieses Verhalten standardmäßig aktiv ist.

Legen Sie für systemweite Jobs beide Units in /etc/systemd/system/ ab und führen Sie dann sudo systemctl daemon-reload und sudo systemctl enable --now yourjob.timer aus. Aktivieren Sie die .timer-Unit — nicht die .service direkt, da der Timer den Zeitplan steuert. Legen Sie sie für benutzereigene Jobs stattdessen in ~/.config/systemd/user/ ab und verwenden Sie systemctl --user enable --now yourjob.timer.

Führen Sie systemd-analyze calendar „<expression>“ aus, um die Syntax zu validieren und zu sehen, wann der Ausdruck das nächste Mal eintritt — zum Beispiel systemd-analyze calendar „*-*-* 03:00:00“. Sobald der Timer installiert ist, zeigt systemctl list-timers jeden aktiven Timer mit seinen letzten und nächsten Laufzeiten an, und journalctl -u yourjob.service streamt die Job-Ausgabe.