Les minuteurs Systemd : l'alternative moderne à cron dont tu avais besoin

Pourquoi j’ai abandonné cron

#

J’utilise cron sur mes serveurs depuis des années. C’est simple, fiable et ça marche. Mais récemment j’ai découvert systemd timers et je ne reviens pas en arrière. La raison principale : logs intégrés dans journald, sans fichiers .log qui traînent partout dans le système, et un meilleur contrôle sur ce qui se passe quand le serveur démarre ou redémarre.

Dans mon cas spécifique, j’avais une sauvegarde qui ne s’exécutait pas si le serveur était arrêté à l’heure programmée. Avec cron, elle était simplement perdue. Avec systemd timers et Persistent=true, la tâche s’exécute dès que le serveur s’allume.

Structure basique : .service + .timer

#

Systemd nécessite deux fichiers :

Le service (/etc/systemd/system/mibackup.service) :

[Unit]
Description=Backup diario de datos
After=network.target

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup.sh
StandardOutput=journal
StandardError=journal

Le timer (/etc/systemd/system/mibackup.timer) :

[Unit]
Description=Ejecuta backup diariamente

[Timer]
OnCalendar=daily
OnCalendar=*-*-* 03:00:00
Persistent=true
Accuracy=1min

[Install]
WantedBy=timers.target

Puis :

sudo systemctl daemon-reload
sudo systemctl enable --now mibackup.timer

OnCalendar : la syntaxe dont tu as besoin

#

OnCalendar est le cron de systemd, mais plus lisible :

• daily → chaque jour à minuit
• weekly → chaque lundi à minuit
• hourly → chaque heure
• *-*-* 03:00:00 → chaque jour à 3 h du matin
• Mon *-*-* 14:30:00 → chaque lundi à 14:30
• *-01,04,07,10-01 00:00:00 → premier jour de chaque trimestre

Tu peux combiner plusieurs lignes OnCalendar :

OnCalendar=*-*-* 03:00:00
OnCalendar=*-*-* 15:00:00

Ceci exécute la tâche deux fois par jour.

Persistent=true : le changement qui m’a convaincu

#

Par défaut, si ton serveur est arrêté quand une tâche est programmée, systemd l’ignore simplement. Avec Persistent=true, systemd se souvient et exécute la tâche la prochaine fois qu’il démarre.

Sur mon serveur domestique, c’est critique. Il n’est pas toujours allumé, et j’ai besoin de garantir que mes sauvegardes s’exécutent même si des heures ont passé.

[Timer]
OnCalendar=daily
Persistent=true

Type=oneshot : pour les tâches qui se terminent

#

Le paramètre Type=oneshot dans le .service indique que le processus se terminera. C’est normal pour les scripts de sauvegarde, synchronisation, etc.

Si tu utilises Type=simple (la valeur par défaut), systemd s’attend à ce que le processus continue à s’exécuter. Ce n’est pas ce que nous voulons ici.

Voir les logs sans fichiers externes

#

Voilà le meilleur : oublie >> /var/log/mibackup.log.

Les logs vont directement dans journald :

# Ver los últimos logs del timer
journalctl -u mibackup.service -n 50

# Ver en tiempo real
journalctl -u mibackup.service -f

# Los últimos 2 horas
journalctl -u mibackup.service --since "2 hours ago"

# Con niveles de prioridad
journalctl -u mibackup.service -p err

Dans ton script tu peux logger avec echo ou logger :

#!/bin/bash
logger "Iniciando backup..."
/backup/script.sh
logger "Backup completado"

Tout est capturé automatiquement.

Liste de contrôle de ce que nous avons fait

#

1. ✅ Tu as créé un .service avec Type=oneshot
2. ✅ Tu as créé un .timer avec OnCalendar et Persistent=true
3. ✅ Tu as rechargé systemd et activé le timer
4. ✅ Tu vérifies les logs avec journalctl, sans fichiers de log supplémentaires

Conseil final

#

Avant de faire confiance à un timer, teste-le manuellement :

# Ejecutar el servicio ahora
sudo systemctl start mibackup.service

# Ver qué pasó
journalctl -u mibackup.service -n 20

Voilà. Systemd timers n’est pas la panacée, mais pour les tâches programmées sur les serveurs modernes, c’est supérieur à cron sur presque tous les aspects. Les logs centralisés dans journald, combinés avec Persistent=true, font qu’il est impossible de ne pas le recommander.

Sur mon serveur domestique, toutes les sauvegardes, nettoyages de cache et synchronisations de données utilisent des timers. Zéro fichiers de log qui traînent. Tout intégré.

Équipement recommandé

#

• Raspberry Pi 3 B+ — Serveur léger à faible consommation pour commencer ton homelab
• Mini PC Intel N100 — Mini PC silencieux et efficace pour serveur domestique 24/7

Liens d’affiliation. Aucun coût supplémentaire pour toi.