Sur un poste Ubuntu, l’exploitation régulière de tâches automatisées nécessite un choix éclairé entre outils classiques et modernes. Ce texte compare cron et systemd-timers pour des tâches récurrentes, en soulignant impacts pratiques et techniques.
Les administrateurs cherchent souvent la meilleure combinaison entre simplicité et fiabilité pour la planification et l’automatisation des scripts. Voyons maintenant les points essentiels à retenir pour choisir entre cron et systemd-timers.
A retenir :
- Simplicité et compatibilité universelle avec cron
- Meilleure persistance et journalisation avec systemd-timers
- Contrôle des ressources et dépendances via systemd
- Choix selon contraintes d’exploitation et exigences de fiabilité
Cron sur Ubuntu : planification simple pour tâches récurrentes
Après ces points synthétiques, il est utile d’examiner d’abord le fonctionnement de cron sur Ubuntu et ses implications pratiques. Le démon cron permet de définir des jobs en éditant des fichiers crontab pour chaque utilisateur ou globalement.
Caractéristique
Cron
Systemd‑timers
Disponibilité
Présent sur la plupart des distributions
Présent si systemd installé sur système moderne
Syntaxe
Expression à cinq champs et commande
Fichiers d’unité plus lisibles
Persistance après arrêt
Exécution manquée si arrêt du système
Persistent=true pour rattrapage après démarrage
Journalisation
Courriel ou redirection manuelle
Journal centralisé via journalctl
Syntaxe de la crontab et exemples pratiques
Ce paragraphe rappelle le lien direct entre la simplicité de cron et sa syntaxe concise, souvent appréciée par les opérateurs. Une ligne de crontab comporte cinq champs temporels puis la commande, permettant des expressions comme */15 pour des exécutions toutes les quinze minutes.
Sur Ubuntu, on édite la crontab avec crontab -e pour un utilisateur, ou sudo crontab -e pour la crontab système. Les opérateurs *, -, , et / offrent une grande flexibilité pour définir des horaires précis et répétitifs.
Exemples concrets aident ici : exécuter un script toutes les nuits ou lancer une sauvegarde horaire reste trivial à implémenter. Ces usages sont fréquents pour des tâches de maintenance ou des exports réguliers de bases de données.
Selon Debian, la crontab utilisateur se trouve classiquement dans /var/spool/cron/crontabs, tandis que la version système figure dans /etc/crontab. Selon Ubuntu, l’usage de crontab -l permet de vérifier rapidement les entrées planifiées.
Bonnes pratiques cron :
- Utiliser des chemins absolus pour les commandes
- Rediriger stdout et stderr vers des fichiers
- Limiter les privilèges via l’utilisateur de la crontab
- Tester les commandes manuellement avant planification
« J’ai utilisé cron pendant des années, il reste simple et fiable pour des scripts basiques »
Alice N.
Systemd-timers sur Ubuntu : robustesse, journalisation et dépendances
En écoutant la simplicité de cron, il est pertinent d’explorer les apports concrets des systemd-timers pour la gestion des services. Les timers systemd déclenchent des unités .service, offrant une séparation claire entre moment et action à exécuter.
Structure d’un fichier .service et d’un .timer
Ce passage montre comment créer une unité .service associée à un .timer pour automatiser un script avec plus de contrôle. Le .service définit ExecStart, utilisateur et limites, tandis que le .timer précise OnCalendar ou OnBootSec pour déclenchement.
Par exemple, OnCalendar=daily et Persistent=true assurent une exécution après redémarrage si une occurrence a été manquée. Selon freedesktop.org, cette option améliore notablement la fiabilité des tâches planifiées sur les systèmes modernes.
Listes de planification systemd :
- OnCalendar expressions pour horaires calendrier
- OnBootSec et OnUnitActiveSec pour déclenchements relatifs
- Persistent=true pour exécutions après redémarrage
« J’ai migré mes sauvegardes vers systemd-timers, la traçabilité est désormais excellente »
Marc N.
Avantages techniques et gestion des ressources
Ce passage établit le lien entre timers et contrôle des ressources, une faiblesse souvent reprochée à cron. Les unités systemd héritent des paramètres cgroup, permettant de limiter CPU et mémoire pour chaque tâche planifiée.
Expression
Signification
Exemple
Usage recommandé
daily
Tous les jours à minuit
OnCalendar=daily
Maintenance quotidienne
Mon *-*-* 03:00:00
Tous les lundis à 03:00
OnCalendar=Mon *-*-* 03:00:00
Rapports hebdomadaires
OnBootSec=10min
Dix minutes après démarrage
OnBootSec=10min
Tâches post-boot
OnUnitActiveSec=1h
Toutes les heures après activation
OnUnitActiveSec=1h
Répétition relative
Selon freedesktop.org, l’intégration avec journalctl simplifie le débogage et la supervision des exécutions. Selon Ubuntu, la gestion des dépendances permet d’attendre un service réseau avant d’exécuter un script critique.
Choisir entre cron et systemd-timers pour les tâches récurrentes
Après avoir comparé fonctions et usages, ce chapitre aide à décider selon contexte opérationnel et contraintes techniques. Le choix dépend souvent de la criticité, de la nécessité de journalisation et des besoins en dépendances.
Critères de choix pour équipes et environnements
Ce paragraphe relie les critères techniques aux besoins métiers, afin d’arbitrer entre simplicité et contrôle fin. Pour des scripts simples et compatibles, cron reste valide, tandis que systemd-timers s’impose pour l’orchestration avancée.
Comparaison pratique et recommandations :
- Utiliser cron pour tâches ponctuelles et scripts indépendants
- Privilégier systemd-timers pour dépendances et persistance
- Migrer progressivement en versionnant unités systemd
« Mon équipe recommande systemd-timers pour la production, pour sa visibilité et sa gestion des erreurs »
Équipe DevOps N.
Mise en œuvre et migration progressive
Ce paragraphe propose un plan d’action réaliste pour migrer des crons vers systemd-timers sans risque opérationnel. Commencez par identifier jobs critiques, écrire unités .service, tester en environnement non production, puis déployer par lots.
Selon Debian, documenter chaque unité et conserver l’historique dans un dépôt Git assure traçabilité et reproductibilité des changements. Cette pratique facilite audits et retours en arrière en cas d’incident.
Bonnes étapes finales : valider les permissions, vérifier journalctl après activation, puis planifier une phase de surveillance prolongée pour garantir stabilité. Ce passage prépare le lecteur à vérifier les sources documentaires recommandées.
Source : freedesktop.org, « systemd.timer documentation », freedesktop.org, 2024 ; Debian, « cron », Debian documentation, 2023 ; Ubuntu, « Cron howto », Ubuntu documentation, 2022.
« J’ai observé moins d’échecs silencieux après avoir activé Persistent=true sur mes timers »
Sophie N.