Journaux et planification : journalctl, cron, timers

Quand un service tombe à 3 h du matin, ce sont les journaux qui racontent ce qui s'est passé. Et beaucoup de tâches d'exploitation sont planifiées : sauvegardes, rotations, nettoyages. Cette leçon est théorique : votre machine de lab n'a ni systemd ni démon de planification.

Ce que vous saurez à la fin : trouver et lire les journaux d'un système (journalctl, /var/log), comprendre la rotation des journaux, planifier une tâche avec cron ou avec un timer systemd, et éviter les pièges classiques des tâches planifiées.

1. Où sont les journaux ?

Source	Commande
Journal de systemd (services, noyau, démarrage)	journalctl
Fichiers texte des services	/var/log/ : syslog ou messages, auth.log ou secure, nginx/…
Messages du noyau	dmesg ou journalctl -k
Connexions	last, lastb (échecs), journalctl -u ssh

journalctl -u nginx --since "today" -p warning   # avertissements et pires, d'aujourd'hui
journalctl -b -1                                  # le démarrage précédent (après un plantage)
journalctl -f                                     # en direct
sudo tail -f /var/log/auth.log                    # tentatives de connexion, sudo…

Niveaux de gravité (-p) : emerg, alert, crit, err, warning, notice, info, debug.

2. La rotation des journaux

Un journal qui grandit sans fin finit par remplir le disque. logrotate les fait tourner : il renomme app.log en app.log.1, compresse les anciens, et supprime les plus vieux.

# /etc/logrotate.d/monapp
/var/log/monapp/*.log {
    daily
    rotate 14          # garder 14 jours
    compress
    missingok
    notifempty
    postrotate
        systemctl reload monapp
    endscript
}

Le journal de systemd a ses propres limites (SystemMaxUse= dans /etc/systemd/journald.conf, journalctl --vacuum-time=2weeks).

3. Planifier avec cron

crontab -e      # la table de l'utilisateur
crontab -l      # l'afficher

# minute heure jour-du-mois mois jour-de-la-semaine  commande
30 2 * * *   /usr/local/bin/sauvegarde.sh >> /var/log/sauvegarde.log 2>&1
*/15 * * * * /usr/local/bin/verifie.sh
0 9 * * 1-5  /usr/local/bin/rapport.sh          # 9 h, du lundi au vendredi

Les pièges classiques :

• cron lance les commandes avec un PATH minimal et sans vos alias : utilisez des chemins complets ;
• sans redirection, la sortie part par courrier local, ou se perd : redirigez vers un journal (>> fichier 2>&1) ;
• le % a un sens spécial dans une crontab : il faut l'échapper (date +\%F) ;
• deux exécutions qui se chevauchent : protégez-vous avec flock -n /tmp/verrou commande.

4. Planifier avec un timer systemd

L'alternative moderne : un .timer qui déclenche un .service (leçon L.9).

# /etc/systemd/system/sauvegarde.timer
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true        # rattrape l'exécution manquée si la machine était éteinte

[Install]
WantedBy=timers.target

sudo systemctl enable --now sauvegarde.timer
systemctl list-timers
journalctl -u sauvegarde.service     # les journaux de chaque exécution, sans redirection à écrire

5. Et dans Kubernetes ?

Linux	Kubernetes
cron, timers	CronJob (leçon 2.4)
journalctl -u, /var/log	kubectl logs, et une collecte centralisée (Loki, Elasticsearch)
logrotate	le kubelet fait tourner les journaux des conteneurs

Une bonne pratique commune : une application conteneurisée écrit ses journaux sur la sortie standard, jamais dans un fichier. C'est la plateforme qui les collecte, les fait tourner et les conserve.

Validez la leçon avec le questionnaire.