Léo Le Mounier -- Langlois

Un administrateur système qui lance des scripts manuellement est un administrateur qui perd son temps. Sauvegardes, renouvellement SSL, nettoyage de logs... tout cela doit être automatique. Cron est le planificateur de tâches historique d'Unix, simple mais impitoyable si on ne connaît pas ses subtilités.

1. La Syntaxe (Les 5 étoiles)

Une ligne Cron se compose toujours de 5 champs temporels suivis de la commande à exécuter.

m h  dom mon dow   command
* * * * * /chemin/vers/script.sh

m : Minute (0-59)
h : Heure (0-23)
dom : Jour du mois (1-31)
mon : Mois (1-12)
dow : Jour de la semaine (0=Dimanche, 1=Lundi...)

Exemples concrets

# Tous les jours à 03h30 du matin
30 03 * * * /root/backup.sh

# Toutes les 15 minutes
*/15 * * * * /usr/bin/php /var/www/script.php

# Le 1er de chaque mois à minuit
0 0 1 * * /root/billing.sh

# Du lundi au vendredi à 8h00
0 08 * * 1-5 /root/wake-up.sh

2. Gérer les Cronjobs

Ne modifiez jamais les fichiers directement. Utilisez la commande dédiée qui vérifie la syntaxe avant d'enregistrer.

# Éditer la crontab de l'utilisateur actuel
crontab -e

# Lister les tâches actuelles
crontab -l

# Éditer la crontab d'un autre utilisateur (root seulement)
sudo crontab -u www-data -e

3. Les pièges mortels (SysAdmin Touch)

90% des problèmes avec Cron viennent de ces deux points. Lisez attentivement.

A. Le PATH n'existe pas

Quand vous êtes connecté en SSH, vous avez un environnement chargé (`.bashrc`). Cron, lui, est minimaliste. Il ne connaît pas vos raccourcis.

Règle d'or : Utilisez toujours des chemins absolus.
❌ python script.py
✅ /usr/bin/python3 /home/leo/script.py

B. Où va la sortie ? (Output)

Si votre script fait un echo "Bonjour" ou affiche une erreur, Cron essaie d'envoyer un email local à l'utilisateur. Si aucun serveur mail n'est installé (Postfix), l'info est perdue.

Il faut toujours rediriger la sortie standard (1) et les erreurs (2) vers un fichier log ou vers le néant (`/dev/null`).

# Bonne pratique : On logue tout pour débugger
0 3 * * * /root/backup.sh >> /var/log/backup.log 2>&1

4. Systemd Timers : Le futur ?

Sur les systèmes modernes (Debian 11+, CentOS 8+), Systemd Timers remplace progressivement Cron. C'est plus complexe mais plus puissant.

Pourquoi utiliser Systemd Timers ?

Gestion des dépendances (attendre que le réseau soit UP avant de lancer).
Logs centralisés dans journalctl.
Précision à la milliseconde.

Cependant, pour des tâches simples, Cron reste le roi indétrônable grâce à sa simplicité.

Conclusion

Avant de dire "mon script ne marche pas dans le cron", vérifiez trois choses : avez-vous mis le chemin absolu ? Avez-vous rendu le script exécutable (`chmod +x`) ? Avez-vous redirigé les logs pour voir l'erreur ?