Cron
Planificateur de tâches Unix classique
Systemd Timer
Planificateur moderne basé sur les services
Comparaison complète entre les planificateurs Cron et Systemd Timer. Apprenez quand utiliser chacun, leurs fonctionnalités, avantages et inconvénients, et comment migrer entre eux.
Quick Comparison
| Feature | ⏰ Cron | ⚙️ Systemd Timer |
|---|---|---|
| Style de planification | Basé sur le temps seulement | Temps ou événement |
| Granularité | Minutes | Microsecondes |
| Dépendances | Aucune | Support complet |
| Journalisation | Email/journaux de base | Intégration journald |
| Tâches par utilisateur | Oui | Oui |
| Timers monotones | Non | Oui |
| Suivi des ressources | Non | Oui (cgroups) |
| Couverture plateforme | Universel | systemd seulement |
| Courbe d'apprentissage | Simple | Modéré |
| Convivialité conteneur | Excellent | Mauvais |
Fonctionnalités principales
Précision de planification
Cron: Niveau minute
Systemd Timer: Niveau microseconde
💡 Why: Les timers systemd supportent une planification plus fine avec une précision à la microseconde, tandis que cron ne support que la granularité au niveau de la minute.
Planification temps réel
Cron: ✅ Support complet
Systemd Timer: ✅ Support complet
💡 Why: Les deux supportent la planification traditionnelle basée sur le temps (par exemple "tous les jours à 3h").
Timers monotones
Cron: ❌ Non supporté
Systemd Timer: ✅ Support complet
💡 Why: Systemd supporte les timers basés sur le temps écoulé depuis le démarrage ou d'autres événements, ce que cron ne peut pas faire.
Déclencheurs d'événements
Cron: ❌ Aucun
Systemd Timer: ✅ Plusieurs événements
💡 Why: Systemd peut se déclencher sur des événements matériels, des changements de chemin et d'autres événements système.
Configuration & Gestion
Format de configuration
Cron: Crontab (simple)
Systemd Timer: Style INI unités
💡 Why: Cron utilise un format crontab simple et bien connu. Systemd utilise des fichiers unité plus complexes.
Planification par utilisateur
Cron: ✅ Supporté
Systemd Timer: ✅ Supporté
💡 Why: Les deux supportent la planification par utilisateur (crontabs utilisateur vs unités utilisateur systemd).
Variables d'environnement
Cron: Limité
Systemd Timer: Support complet
💡 Why: Systemd offre une meilleure gestion des variables d'environnement via les fichiers de service.
Gestion des dépendances
Cron: ❌ Aucune
Systemd Timer: ✅ Support complet
💡 Why: Les timers systemd peuvent dépendre de services, sockets, cibles et autres unités.
Journalisation & Surveillance
Journalisation intégrée
Cron: Email/logs
Systemd Timer: journald
💡 Why: Systemd s'intègre étroitement avec journald pour des journaux structurés et recherchables.
Historique des tâches
Cron: Limité
Systemd Timer: ✅ Suivi
💡 Why: Systemd conserve un historique détaillé des déclenchements de timer et des résultats de service.
Surveillance des ressources
Cron: ❌ Aucune
Systemd Timer: ✅ cgroups
💡 Why: Systemd suit l'utilisation des ressources via cgroups pour chaque service.
Gestion des échecs
Cron: Email seulement
Systemd Timer: Options multiples
💡 Why: Systemd supporte les déclencheurs on-failure, les politiques de redémarrage et les réactions basées sur les dépendances.
Performance & Ressources
Utilisation mémoire
Cron: ~1-2 MB
Systemd Timer: ~5-10 MB
💡 Why: Le démon cron utilise une mémoire minimale. Systemd est déjà en cours d'exécution, donc les timers ajoutent une surcharge négligeable.
Temps de démarrage
Cron: Rapide
Systemd Timer: Instantané
💡 Why: Systemd fait partie de init, déjà en cours d'exécution au démarrage.
Extensibilité
Cron: Bonne
Systemd Timer: Excellente
💡 Why: Systemd gère des milliers d'unités plus efficacement avec la gestion des processus moderne.
Intégration système
Cron: Autonome
Systemd Timer: Intégré
💡 Why: Les timers systemd sont natifs pour les systèmes basés sur systemd.
Plateforme & Compatibilité
Support Linux
Cron: ✅ Universel
Systemd Timer: systemd seulement
💡 Why: Cron fonctionne sur tous les systèmes Linux. Les timers systemd ne fonctionnent que sur les distributions basées sur systemd.
Support Unix/BSD
Cron: ✅ Oui
Systemd Timer: ❌ Non
💡 Why: Cron est disponible sur pratiquement tous les systèmes de type Unix.
Support macOS
Cron: ✅ launchd/cron
Systemd Timer: ❌ Non
💡 Why: macOS utilise launchd (pas systemd), mais cron est disponible.
Support conteneur
Cron: ✅ Simple
Systemd Timer: Complexe
💡 Why: Cron fonctionne dans des conteneurs minimaux. Systemd nécessite un init systemd complet.
Practical Examples
Sauvegarde quotidienne simple
Cron
# Exécuter la sauvegarde à 2h du matin
0 2 * * * /root/backup.sh
Cron est plus simple pour cette tâche de base. Systemd nécessite deux fichiers (timer + service) mais offre une persistance à travers les redémarrages.
Exécuter 15 minutes après le démarrage
Cron
# Pas facilement supporté
# Nécessiterait @reboot avec sleep
Systemd supporte nativement l'exécution différée après le démarrage. Cron nécessiterait des contournements complexes.
Exécuter lorsque le réseau est actif
Cron
# Non supporté
Systemd peut attendre des états système spécifiques. Cron n'a aucune perception des dépendances.
Migration Guide
Cron → Systemd Timer
- → Créez à la fois des fichiers .timer et .service (entrée cron = timer + service combiné)
- → Utilisez OnCalendar pour la planification basée sur le temps (convertit les expressions cron)
- → Utilisez Persistent=true pour exécuter les tâches manquées pendant les temps d'arrêt
- → Déplacez les variables d'environnement de crontab vers [Service] Environment=
- → Remplacez la sortie email par la journalisation journald
- → Convertissez les crontabs utilisateur en unités utilisateur systemd (~/.config/systemd/user/)
- → Utilisez systemctl list-timers pour voir tous les timers (similaire à crontab -l)
Cron → Systemd Timer
- → Perdre la gestion des dépendances - le script doit gérer les dépendances
- → Convertir OnCalendar en expressions cron (minute heure jour mois jour_de_la_semaine)
- → Remplacer les timers monotones (OnBootSec) par @reboot et sleep
- → Supprimer les déclencheurs basés sur des événements (cron est temps seulement)
- → Les variables d'environnement vont dans crontab ou le script
- → La journalisation doit être gérée manuellement (syslog, fichiers personnalisés)
- → Aucune persistance intégrée - suivre le dernier exécution manuellement dans les scripts
Frequently Asked Questions
Lequel dois-je choisir pour un nouveau serveur Linux ? ▼
Cron et systemd peuvent-ils coexister ? ▼
Comment voir toutes les tâches planifiées comme crontab -l ? ▼
Les timers systemd fonctionnent-ils dans les conteneurs Docker ? ▼
Cron est-il déprécié ? ▼
Les timers systemd peuvent-ils envoyer des emails en cas d'échec comme cron ? ▼
Lequel utilise moins de ressources système ? ▼
Comment planifier une tâche toutes les 10 secondes ? ▼
Verdict: Aucun - Choisir en fonction des besoins
Cron et systemd sont tous deux des planificateurs de tâches puissants servant des besoins différents. **Cron reste le choix universel** pour une planification simple et portable sur tous les systèmes de type Unix. **Les timers systemd excellent** sur les distributions Linux modernes nécessitant des dépendances complexes, des déclencheurs d'événements et une journalisation intégrée.
Recommendation
Utilisez **cron** pour les tâches périodiques simples, la compatibilité multi-plateforme, les systèmes legacy et les conteneurs. Utilisez les **timers systemd** pour les serveurs Linux modernes, l'orchestration de services, la planification pilotée par les événements et lorsque vous avez besoin d'une intégration étroite avec les services système.