Automatiser des opérations récurrentes sur un serveur Linux économise du temps et réduit les erreurs humaines en production. Les administrateurs combinent souvent des outils classiques et modernes pour obtenir des exécutions fiables et traçables.
Ce dossier fait le pont entre cron et systemd, en montrant usages concrets, pièges fréquents et bonnes pratiques pour l’automatisation. La suite présente des points clés faciles à retenir avant d’entrer dans le détail.
A retenir :
- Planification stable des tâches récurrentes sans supervision humaine
- Choix entre cron et unités systemd selon granularité et dépendances
- Surveillance des jobs via logs et status des services Linux
- Scripts shell robustes et permissions gérées pour fiabilité
Les tâches cron : principes, syntaxe et cas d’usage
Cette section prolonge l’idée générale en expliquant le fonctionnement historique de cron et son intérêt pour les tâches simples. Les administrateurs apprécient cron pour sa simplicité et sa compatibilité avec des environnements légers.
Nous détaillons la structure des crontabs, des exemples opérationnels et des vérifications courantes pour s’assurer que les jobs tournent comme prévu. La fin de ce développement prépare l’examen des minuteries systemd, plus adaptées aux besoins complexes.
Structure des crontabs et champs essentiels
La crontab suit une ligne par tâche composée de cinq champs temporels puis d’une commande à exécuter. Cette organisation simple rend cron immédiat à déployer pour des sauvegardes et nettoyages réguliers.
Minute
Heure
Jour
Mois
Jour semaine
Exemple
0
3
*
*
*
Sauvegarde quotidienne
*/5
*
*
*
*
Job toutes les 5 minutes
0
0
1
*
*
Nettoyage mensuel
30
23
*
*
6
Tâche hebdomadaire samedi
Exemples concrets aident à éviter les erreurs de syntaxe et à préciser l’utilisateur qui exécute la commande. Pour GLPI, un cron typique exécute le script PHP sous l’utilisateur web pour garantir des droits cohérents.
Selon la documentation Debian, la plupart des distributions conservent les crontabs sous /etc/cron.d et gèrent le démon crond pour exécuter les tâches. Selon Ubuntu, la commande crontab -e reste l’outil de référence pour éditer les crontabs utilisateur.
À retenir pour les opérations : surveiller les logs système et valider l’environnement d’exécution des scripts avant mise en production. Cette vérification facilite le passage suivant vers les minuteries systemd.
Liste des vérifications :
- Permissions du script et de l’utilisateur d’exécution
- Variables d’environnement explicitement définies
- Redirections de sortie vers des logs dédiés
- Tests manuels avant planification
« J’ai réduit les erreurs de sauvegarde en définissant un environnement complet dans mon script bash »
Camille N.
Planification avancée avec les minuteries systemd
En raison de l’évolution des distributions, systemd propose des minuteries plus expressives et intégrées aux services Linux. Ces unités conviennent mieux quand la planification dépend d’un état système ou de dépendances complexes.
Nous expliquons la structure .timer et .service, les mots-clés utiles et les cas où systemd surpasse cron pour la robustesse. La dernière partie montre comment activer et inspecter des minuteries en production.
Concepts clés des unités systemd et mots-clés
Une minuterie systemd (.timer) s’appuie sur une unité de service (.service) qui contient la commande à lancer, ce couplage est puissant pour gérer dépendances. Les mots-clés comme OnCalendar et OnBootSec offrent un contrôle fin des horaires.
Mot-clé
Signification
Usage pratique
OnCalendar
Calendrier absolu semblable à cron
Exécutions régulières à heure fixe
OnBootSec
Délais relatifs au démarrage système
Tâches post-démarrage
OnUnitActiveSec
Relatif au dernier fonctionnement du service
Mesures périodiques liées au service
Persistent
Rattrapage des exécutions manquées
Planification fiable après interruptions
Selon la page man systemd.timer, l’option Persistent permet de relancer un job manqué lors du redémarrage si nécessaire. Selon freedesktop, OnCalendar accepte des formats riches qui dépassent la simple syntaxe cron.
Cas d’usage privilégiés :
- Tâches dépendantes d’un service démarré
- Jobs devant rattraper des exécutions manquées
- Planification avec précision temporelle variable
- Surveillance via systemctl et journald
« Passer à systemd a simplifié la gestion des dépendances sur notre cluster »
Alex N.
Minuteries transitoires et pratiques d’activation
Les minuteries transitoires permettent une planification à la volée sans déposer de fichiers unitaires, pratique pour tests ou tâches temporaires. La commande systemd-run crée des unités temporaires qui disparaissent au redémarrage selon le contexte d’exécution.
Pour activer une minuterie persistante, copier les fichiers dans /etc/systemd/system puis lancer systemctl enable et start. Selon la documentation Ubuntu, bien définir le champ [Install] permet l’activation automatique au démarrage.
Bonnes pratiques systemd :
- Nommer unités de façon descriptive
- Documenter le comportement dans la section [Unit]
- Vérifier les journaux via journalctl pour chaque run
- Tester les unités avec systemctl start avant enable
« Un run manuel m’a permis d’identifier des erreurs d’environnement avant la mise en production »
Martin N.
Intégration pratique : scripts shell, services et supervision
Après avoir choisi cron ou systemd, l’étape suivante consiste à écrire des shell script robustes et à configurer la supervision des services Linux. L’approche combine gestion des droits, logs et notifications pour maintenir une fiabilité opérationnelle.
Cette section offre des exemples concrets de scripts, d’intégration avec GLPI/FusionInventory et des méthodes de test. La fin aborde la surveillance continue et la réponse aux incidents liés aux jobs automatisés.
Exemples de scripts shell et intégration GLPI
Un script de backup typique commence par des vérifications d’espace, des sauvegardes compressées et des rotations de logs pour éviter la saturation. Les scripts doivent toujours rediriger la sortie et gérer les codes de retour explicitement.
Pour GLPI, la tâche cron qui exécute le job PHP peut ressembler à l’exemple cité plus haut, déclenchée toutes les cinq minutes sous l’utilisateur apache. Selon la documentation GLPI, l’appel direct du front/cron.php est la méthode recommandée pour les installations traditionnelles.
Checklist script :
- Validation des paramètres en début d’exécution
- Redirections stdout/stderr vers des fichiers
- Gestion claire des codes de sortie
- Notifications en cas d’échec critique
« Un log dédié m’a sauvé lors d’un incident nocturne en production »
Sarah N.
Surveillance, tests et réponses aux incidents
Surveiller les tâches implique d’exploiter journalctl, systemctl status et les fichiers de log produits par les scripts. Configurer des alertes réduit le temps moyen de résolution en cas d’échec d’un job critique.
Des tests peuvent être automatisés avec des runs manuels et des minuteries transitoires pour valider le comportement avant déploiement. Selon la pratique industrielle, simuler des pannes montre la résilience des procédures d’automatisation.
Procédure de test :
- Exécuter la tâche manuellement pour vérifier le comportement
- Déployer en mode transitoire pour observation
- Analyser les logs et corriger les erreurs détectées
- Planifier une reprise automatique si nécessaire
Source : Freedesktop.org, « systemd.timer — man page », freedesktop.org, 2023 ; Debian, « Cron », Debian Documentation, 2022 ; Ubuntu, « Cron and systemd », Ubuntu Documentation, 2024.