Guide des temporisateurs Systemd : Remplacer les tâches Cron pour une planification fiable

Pendant des décennies, cron a été la norme de facto pour la planification de tâches sur les systèmes Linux et de type Unix. Sa simplicité et son omniprésence en ont fait un outil indispensable pour les administrateurs comme pour les développeurs. Cependant, à mesure que les systèmes Linux ont évolué, notamment avec l'avènement de systemd en tant que gestionnaire de système et de services, des mécanismes de planification plus robustes et intégrés sont devenus disponibles. Les unités de temporisateur systemd (fichiers .timer) offrent une alternative moderne, puissante et souvent supérieure aux tâches cron traditionnelles.

Ce guide explorera les avantages des temporisateurs systemd, détaillant leur intégration transparente avec le reste de l'écosystème systemd. Nous fournirons une présentation complète de la configuration des fichiers de temporisateur (.timer) et de service (.service), vous permettant de créer des tâches planifiées robustes, reproductibles et faciles à gérer. À la fin de cet article, vous comprendrez pourquoi les temporisateurs systemd sont souvent le choix privilégié pour une planification de tâches fiable dans les environnements Linux modernes.

Comprendre les temporisateurs Systemd

Les temporisateurs systemd sont des fichiers d'unité systemd qui contrôlent le moment où d'autres unités systemd, généralement des unités de service, sont activées. Contrairement à cron, qui est un démon autonome, les temporisateurs systemd font partie intégrante du système d'initialisation systemd. Cette intégration profonde apporte plusieurs avantages significatifs, notamment en matière de fiabilité, de journalisation et de gestion des ressources.

Un temporisateur systemd fonctionne toujours en conjonction avec une autre unité, le plus souvent une unité de service. Le fichier .timer définit quand un événement doit se produire, et le fichier .service correspondant définit quelle action doit être effectuée lorsque cet événement est déclenché. Cette séparation claire des préoccupations rend les temporisateurs systemd hautement modulaires et flexibles.

Principaux avantages des temporisateurs Systemd par rapport à Cron

Bien que cron soit fonctionnel, les temporisateurs systemd pallient bon nombre de ses limitations, offrant une solution de planification plus robuste et plus riche en fonctionnalités :

Fiabilité et Persistance : Si un temporisateur systemd est configuré avec Persistent=true et que le système est éteint pendant une exécution planifiée, le service associé sera exécuté peu de temps après le redémarrage du système. Les tâches cron, en revanche, manquent simplement leurs exécutions planifiées si le système est hors tension.
Intégration avec systemd : Les temporisateurs bénéficient de la journalisation puissante de systemd (via journalctl), de la gestion des dépendances et du contrôle des ressources (cgroups). Cela signifie une meilleure surveillance, des rapports d'erreurs plus clairs et la possibilité de définir des séquences de démarrage complexes ou des limites de ressources pour les tâches planifiées.
Reproductibilité et Contrôle de Version : Les fichiers d'unité systemd sont des fichiers texte brut qui peuvent être facilement stockés dans des systèmes de contrôle de version. Cela permet des déploiements reproductibles et un suivi plus facile des modifications des tâches planifiées sur plusieurs systèmes.
Planification basée sur les événements : Au-delà de la simple planification basée sur le temps, les temporisateurs systemd peuvent être déclenchés par rapport au démarrage du système (OnBootSec) ou après la dernière activation d'une unité (OnUnitActiveSec), offrant des options de planification plus dynamiques.
Expressions temporelles flexibles : systemd propose un ensemble riche d'expressions d'événements de calendrier, souvent plus lisibles et polyvalentes que la syntaxe de cron, incluant l'heure, le jour, la semaine et des dates/heures spécifiques.
Gestion des ressources et dépendances : Les services systemd lancés par des temporisateurs héritent de l'environnement systemd, y compris les paramètres cgroup, et peuvent déclarer des dépendances vis-à-vis d'autres unités systemd (par exemple, attendre que le réseau ou une base de données soit disponible avant l'exécution).
Gestion des sorties standard/erreurs : systemd capture automatiquement stdout et stderr des services lancés par des temporisateurs et les dirige vers le journal système, ce qui rend le débogage et l'audit beaucoup plus simples qu'avec la sortie par e-mail de cron ou la redirection manuelle.

Configuration des temporisateurs Systemd

La configuration d'un temporisateur systemd implique la création de deux fichiers d'unité : une unité de service (.service) et une unité de temporisateur (.timer). Ces fichiers sont généralement placés dans /etc/systemd/system/ pour les temporisateurs à l'échelle du système ou dans ~/.config/systemd/user/ pour les temporisateurs spécifiques à l'utilisateur.

1. L'unité de service (fichier `.service`)

L'unité de service définit la commande ou le script réel à exécuter. Il s'agit d'un fichier de service systemd standard, mais souvent conçu pour être exécuté de manière non interactive et pour effectuer une tâche spécifique.

Exemple : /etc/systemd/system/mytask.service

[Unit]
Description=My Scheduled Task Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/mytask.sh
User=myuser
Group=mygroup
# Optional: Limit resources
# CPUShares=512
# MemoryLimit=1G

[Install]
WantedBy=multi-user.target

Explication :

[Unit] : Contient des informations génériques sur l'unité.
- Description : Une description lisible par l'homme.
[Service] : Définit la configuration spécifique au service.
- Type=oneshot : Indique que le service exécute une seule commande puis se termine. Ceci est courant pour les tâches planifiées.
- ExecStart : La commande ou le script à exécuter. Fournir le chemin complet.
- User, Group : Définit l'utilisateur et le groupe sous lesquels la commande s'exécutera. Exécutez toujours les tâches avec le moins de privilèges nécessaires.
- CPUShares, MemoryLimit : (Facultatif) systemd vous permet de définir des limites de ressources pour les services, en tirant parti des cgroups.
[Install] : Définit la manière dont l'unité doit être activée.
- WantedBy=multi-user.target : Bien que présente, cette section est souvent moins critique pour les services déclenchés par temporisateur, car l'unité de temporisateur elle-même détermine généralement l'activation. Cependant, elle peut être utile si vous souhaitez également que le service puisse être activé manuellement ou s'intégrer à d'autres cibles systemd.

2. L'unité de temporisateur (fichier `.timer`)

L'unité de temporisateur définit quand l'unité de service correspondante doit être activée. Elle doit porter le même nom que son homologue de service (par exemple, mytask.timer pour mytask.service).

Exemple : /etc/systemd/system/mytask.timer

[Unit]
Description=Runs mytask.service daily

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=600
AccuracySec=1min

[Install]
WantedBy=timers.target