Faites passer une ligne de crontab vers un timer systemd.

Il prend une seule ligne de crontab — les cinq champs horaires plus la commande — et génère une configuration systemd équivalente : une unité .timer avec une expression OnCalendar= qui correspond à votre planification, et une unité .service qui exécute votre commande. Il dresse aussi la liste des notes de migration qui signalent tout ce que systemd gère différemment, comme le répertoire de travail implicite ou l’environnement. Tout est calculé dans votre navigateur.

Non. Le convertisseur fonctionne 100 % côté client. Votre ligne cron et votre commande sont analysées et traduites dans l’onglet de votre navigateur — rien n’est envoyé à un serveur, et il n’y a ni compte ni inscription. Vous pouvez coller en toute sécurité des commandes et des chemins internes.

Un ensemble de champs crontab est réécrit dans la syntaxe de calendrier OnCalendar= de systemd — par exemple « 0 3 * * * » devient « *-*-* 03:00:00 » (tous les jours à 03:00). Les listes, plages et valeurs de pas sont converties en leurs équivalents OnCalendar, et les @macros courantes comme @daily et @hourly sont converties en leurs formes de timer canoniques. Après avoir installé le timer, vous pouvez confirmer les prochaines exécutions avec « systemctl list-timers ».

Les timers vous offrent une journalisation structurée via le journal (journalctl -u your.service), un ordonnancement des dépendances, des limites de ressources, une nouvelle tentative automatique et une planification précise ou monotone, ainsi que Persistent=true pour qu’une exécution manquée puisse se déclencher au prochain démarrage. C’est la primitive de planification native des distributions Linux modernes sous systemd, où le crond par utilisateur n’est souvent même pas installé.

Quelques comportements de cron n’ont pas d’équivalent direct en OnCalendar= et apparaissent plutôt sous forme de notes de migration — les extensions cron non standard ou propres à un fournisseur, MAILTO pour l’envoi de la sortie par e-mail (utilisez journald ou un gestionnaire OnFailure=), et les affectations d’environnement ligne par ligne (déplacez-les vers Environment= ou un EnvironmentFile= dans le .service). Le convertisseur les signale afin que rien ne change de sens en silence.

Non. Il s’agit d’un utilitaire communautaire et indépendant qui n’est ni affilié au projet systemd ni à aucune implémentation de cron, et qui n’est pas approuvé par eux. Il modélise les formats standard d’unités crontab et systemd par souci de familiarité et ne les nomme que pour décrire ce qu’il convertit.

@reboot n’a pas d’équivalent OnCalendar= et se traduit par OnBootSec=1min dans la section [Timer], de sorte que la tâche se déclenche une fois peu après chaque démarrage. @hourly se développe en OnCalendar=*-*-* *:00:00, @daily en OnCalendar=*-*-* 00:00:00, @weekly en OnCalendar=Sun *-*-* 00:00:00, @monthly en OnCalendar=*-*-01 00:00:00, et @yearly en OnCalendar=*-01-01 00:00:00. Le convertisseur gère automatiquement tous ces cas et signale le cas particulier de @reboot.

Ajoutez Persistent=true à la section [Timer] à côté de votre ligne OnCalendar=. systemd enregistre sur le disque l’heure du dernier déclenchement et, si l’heure planifiée est passée pendant que la machine était éteinte, exécute la tâche immédiatement au prochain démarrage. Le convertisseur inclut toujours Persistent=true dans l’unité .timer générée afin que ce comportement soit actif par défaut.

Pour les tâches à l’échelle du système, placez les deux unités dans /etc/systemd/system/, puis exécutez sudo systemctl daemon-reload et sudo systemctl enable --now yourjob.timer. Activez l’unité .timer — et non le .service directement, puisque c’est le timer qui contrôle la planification. Pour les tâches par utilisateur, placez-les dans ~/.config/systemd/user/ et utilisez plutôt systemctl --user enable --now yourjob.timer.

Exécutez systemd-analyze calendar « <expression> » pour valider la syntaxe et voir quand l’expression s’écoulera la prochaine fois — par exemple systemd-analyze calendar « *-*-* 03:00:00 ». Une fois le timer installé, systemctl list-timers affiche chaque timer actif avec ses heures de dernière et de prochaine exécution, et journalctl -u yourjob.service diffuse la sortie de la tâche.