À qui s’adresse le tutoriel « Cron et at : planifier des tâches fiables » ?

Aux débutants et praticiens DevOps qui veulent une procédure concrète, avec prérequis, étapes et vérifications. Voir la page pour le niveau exact et les labs.

Faut-il un lab cloud ou une VM pour suivre linux-cron-planification ?

La plupart des labs tournent en Free Tier / VM locale. Suivez la section Prérequis de la page pour les outils, droits et coûts éventuels.

Cron et at : planifier des tâches fiables

À la fin de ce tutoriel, vous saurez lire et écrire une crontab, distinguer cron utilisateur / système (/etc/cron.d, cron.daily), comprendre anacron et les one-shot at, éviter le piège du PATH minimal, et débugger un job silencieux — avant d’automatiser des backups dans le chapitre suivant. Focus cron planification : ce n’est pas un redo des systemd timers (OnCalendar / Persistent) ; on les croise pour savoir quand migrer.

Niveau : Intermédiaire · Temps estimé : 35–45 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 (crond) · Dernière vérification : 2026-09-11

Slug proposé : linux-cron-planification · Série : Linux Admin · Remplace / fusionne : N/A — création (chapitre 5, lot 2)

Prérequis

Hub Linux Admin ; chapitre précédent LVM volumes (stockage prêt avant backups planifiés)
Bases : processus & systemd, logs journalctl (pour lire cron / crond)
Compte non-root avec sudo ; machine jetable (VM / WSL / VPS lab)
Éditeur confortable (nano ou vim) ; labs sous /tmp/lab-cron sans secrets

Coût : 0 €. Ne touchez pas une crontab de production sans snapshot / export préalable (crontab -l).

Ce que nous allons construire

Pourquoi planifier (cron · at · anacron · timers)
  → Syntaxe crontab (5 champs) + crontab -e/-l
  → Environnement : SHELL, PATH, MAILTO
  → Système : /etc/crontab · /etc/cron.d · run-parts
  → at / batch (one-shot)
  → Lab script + crontab user + debug logs
  → Nettoyage

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « cron Linux : crontab 5 champs, cron.d, anacron, at, vs systemd timer ».)

Chapitre 5 de Linux Admin : après disques/LVM, on planifie avant backups rsync. Un cron mal PATH-é « marche en manuel » et échoue la nuit — c’est le bug n°1 en ops.

Étape 1 — Cron, at, anacron, timers : quoi choisir ?

Besoin	Outil	Quand l’utiliser
Récurrence fixe (minute → mois)	cron / crontab	Jobs user ou machine classiques
Machine souvent éteinte (laptop)	anacron	Rattrapage daily/weekly si l’échéance a été manquée
One-shot « dans 20 min »	`at` / `batch`	Patch unique, rappel lab
Logs unit + Persistent=	systemd timer	Services modernisés, flotte, dépendances d’units

Ubuntu/Debian : service souvent cron.service. Rocky/Alma : crond.service. Même idée ; noms d’units différents.

# Service présent ?
systemctl is-active cron 2>/dev/null || systemctl is-active crond 2>/dev/null || true
systemctl is-enabled cron 2>/dev/null || systemctl is-enabled crond 2>/dev/null || true
# Qui peut utiliser crontab ?
ls -l /etc/cron.allow /etc/cron.deny 2>/dev/null || echo "pas de allow/deny explicite"

Étape 2 — Syntaxe crontab (5 champs)

Format user (crontab -e) :

# m  h  dom mon dow  commande
# *  *   *   *   *   commande

Champ	Valeurs	Exemple
minute	0–59	`*/15` = toutes les 15 min
heure	0–23	`3` = 03:00
jour du mois	1–31	`1` = le 1er
mois	1–12 ou noms	`1-6` = jan–juin
jour semaine	0–7 (0 et 7 = dim)	`1-5` = lun–ven

# Exemples à coller en commentaire dans un lab (ne pas activer en prod)
cat << 'EOF'
# Chaque jour à 02:30 — rapport lab
30 2 * * * /tmp/lab-cron/rapport.sh
# Toutes les 15 min en semaine
*/15 * * * 1-5 /tmp/lab-cron/ping-lab.sh
# 1er du mois à 04:00
0 4 1 * * /tmp/lab-cron/mensuel.sh
# Dimanche 23:00
0 23 * * 0 /tmp/lab-cron/hebdo.sh
EOF

Commandes utiles :

crontab -l          # lister (vide = aucune)
crontab -e          # éditer (EDITOR/VISUAL)
# crontab -r        # ATTENTION : supprime TOUTE la crontab user — préférer éditer

Sur /etc/crontab et fichiers /etc/cron.d/*, un 6ᵉ champ user s’intercale avant la commande (root, www-data…).

Étape 3 — Environnement : PATH et MAILTO

Cron n’hérite pas de votre shell interactif. PATH est souvent /usr/bin:/bin — d’où les « marche en SSH, échoue en cron ».

mkdir -p /tmp/lab-cron
# Voir l’environnement qu’un job verrait (approche lab)
cat > /tmp/lab-cron/env-dump.sh << 'EOF'
#!/usr/bin/env bash
set -euo pipefail
{
  date -Is
  echo "USER=${USER:-}"
  echo "HOME=${HOME:-}"
  echo "PATH=$PATH"
  echo "PWD=$PWD"
  which curl || true
  which python3 || true
} >> /tmp/lab-cron/env.log
EOF
chmod +x /tmp/lab-cron/env-dump.sh

Bonnes pratiques dans la crontab (en-tête) :

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=""
# Puis les lignes jobs — chemins ABSOLUS vers scripts

MAILTO="" : évite d’inonder une boîte si le MTA local envoie stdout/stderr.
Redirigez explicitement : >> /tmp/lab-cron/job.log 2>&1.
Jamais de secrets en clair dans la crontab (tokens, mots de passe) — fichiers mode 600 hors git, ou secrets manager.

Étape 4 — Cron système, run-parts et anacron

# Fichiers système (lecture)
ls -la /etc/crontab /etc/cron.d 2>/dev/null | head
ls /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly 2>/dev/null
# anacron souvent branché sur daily/weekly/monthly (Debian/Ubuntu)
command -v anacron && anacron -T 2>/dev/null || true
head -n 20 /etc/crontab 2>/dev/null || true

Emplacement	Rôle
`crontab -e` (user)	Jobs de votre compte
`/etc/crontab`	Table système (+ colonne user)
`/etc/cron.d/*.conf`	Snippets paquets / ops (même format que `/etc/crontab`)
`cron.hourly\|daily\|…`	Scripts exécutés via `run-parts` (noms sans point bizarre)

anacron : si le laptop était éteint à 02:30, le job « daily » part au prochain allumage (dans la fenêtre configurée). Utile pour postes ; sur serveur 24/7, cron classique suffit souvent.

Ne créez un fichier sous /etc/cron.d/ qu’avec sudo et un nom simple (lab-cron OK ; lab.cron peut être ignoré par run-parts selon les règles).

Étape 5 — `at` et `batch` : one-shot

# Paquet parfois séparé
command -v at || sudo apt-get install -y at 2>/dev/null || sudo dnf install -y at 2>/dev/null || true
# File d’attente
atq 2>/dev/null || true
# Exemple : dans 2 minutes, écrire un horodatage (lab)
echo 'date -Is >> /tmp/lab-cron/at-run.log' | at now + 2 minutes 2>/dev/null || echo "at indisponible — skip lab one-shot"
atq 2>/dev/null || true

batch lance quand la charge le permet. Pour un rappel unique ou un reboot différé de lab, at évite d’oublier une ligne cron permanente.

Étape 6 — Lab : script + crontab user

mkdir -p /tmp/lab-cron
cat > /tmp/lab-cron/rapport.sh << 'EOF'
#!/usr/bin/env bash
set -euo pipefail
stamp=$(date -Is)
load=$(cut -d' ' -f1-3 /proc/loadavg)
disk=$(df -h / | awk 'NR==2{print $5}')
echo "$stamp load=$load root_use=$disk" >> /tmp/lab-cron/rapport.log
EOF
chmod +x /tmp/lab-cron/rapport.sh
/tmp/lab-cron/rapport.sh
tail -n 3 /tmp/lab-cron/rapport.log

Installer une entrée toutes les minutes (lab agressif — retirez après) :

# Sauvegarde éventuelle
crontab -l > /tmp/lab-cron/crontab.bak 2>/dev/null || true
# Ajouter le job sans écraser le reste
( crontab -l 2>/dev/null | grep -v '/tmp/lab-cron/rapport.sh' ; 
  echo 'SHELL=/bin/bash' ; 
  echo 'PATH=/usr/local/bin:/usr/bin:/bin' ; 
  echo '* * * * * /tmp/lab-cron/rapport.sh' ) | crontab -
crontab -l
# Attendre ~70 s puis :
sleep 70
tail -n 5 /tmp/lab-cron/rapport.log

Validé si : le log grossit sans intervention manuelle, horodatages espacés d’≈1 minute.

Étape 7 — Debug et nettoyage

# Logs cron (adaptez le nom d’unit)
journalctl -u cron -n 30 --no-pager 2>/dev/null || journalctl -u crond -n 30 --no-pager 2>/dev/null || true
# Debian/Ubuntu texte
sudo grep -i CRON /var/log/syslog 2>/dev/null | tail -n 20 || sudo grep -i CRON /var/log/cron 2>/dev/null | tail -n 20 || true

Nettoyage lab (remettez votre crontab précédente si besoin) :

# Retirer uniquement le job lab
( crontab -l 2>/dev/null | grep -v '/tmp/lab-cron/rapport.sh' ) | crontab - 2>/dev/null || true
# Ou restaurer :
# crontab /tmp/lab-cron/crontab.bak
rm -rf /tmp/lab-cron
crontab -l 2>/dev/null || echo "crontab user vide — OK"

Erreurs fréquentes

Symptôme	Cause	Correction
Marche en SSH, échoue en cron	PATH / binaire relatif	PATH explicite + chemins absolus
Aucune sortie visible	stdout perdu / pas de mail	`>> fichier 2>&1` ; `MAILTO`
`crontab -r` par erreur	Suppression totale	Restaurer backup ; documenter avant
Job `/etc/cron.d` ignoré	Nom avec `.` / droits	Nom simple ; `chmod 644` ; user dans la ligne
Double exécution	cron et timer sur la même tâche	Choisir un déclencheur
Fuseau / heure « bizarre »	TZ serveur ≠ attendu	`timedatectl` ; `CRON_TZ=` si supporté
`permission denied` script	Pas `+x` ou noexec	`chmod +x` ; filesystem exec

Quiz (3 questions)

1. Combien de champs temporels dans une crontab utilisateur ?
– A. 3
– B. 5
– C. 7

2. Pourquoi un script « OK en manuel » échoue souvent sous cron ?
– A. Parce que cron désactive sudo
– B. Parce que l’environnement (surtout PATH) est minimal
– C. Parce que bash est interdit

3. Quel outil pour un one-shot « dans 10 minutes » sans laisser une ligne permanente ?
– A. at
– B. lvextend
– C. chmod -R 777

Réponses : 1‑B · 2‑B · 3‑A

FAQ

Faut-il abandonner cron au profit des systemd timers ?
Non systématiquement. Cron reste simple, portable et partout. Passez aux systemd timers quand vous voulez journalctl -u, Persistent=, dépendances d’units ou déploiement Git d’units. Les deux cohabitent souvent.

Où mettre un job « système » pour une appli ?
Préférez un fichier dédié sous /etc/cron.d/mon-app (colonne user) plutôt que d’éditer /etc/crontab à la main. Ou une crontab du user de service si l’équipe gère déjà ce compte.

Comment tester sans attendre demain 03:00 ?
Exécutez le script à la main avec env -i + le même PATH que la crontab ; en lab, une ligne */1 * * * * quelques minutes puis retrait ; pour un one-shot, at now + 1 minute.

Pour aller plus loin

man 5 crontab, man cron, man anacron, man at
Suite : Backups rsync · pont timers : systemd timers
Logs : journalctl

Maillage série Linux Admin


← Précédent	LVM volumes : PV, VG, LV, extend et snapshots
→ Suivant	Backups rsync : stratégie 3-2-1
Hub	Linux Admin
Aussi	systemd timers · logs journalctl

Meta publication (à remplir dans Rank Math / SEO)

Title SEO : Cron Linux : crontab, anacron et at (2026)
Meta description (≤ 155) : Planifiez des tâches avec cron, crontab, anacron et at. Guide Linux Admin DevOps 2026.
Focus keyphrase : cron linux
KW secondaires : crontab, anacron, at linux, planification cron, cron.d
Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
Image mise en avant : assets/web/devopelastichayway/cover-linux-cron-planification-1200x630.webp (Visuels Linux — WebP 1200×630)
Catégorie : Linux · Niveau : Intermédiaire
Slug : linux-cron-planification
Statut : HOLD — draft only (ne pas publier)

← Retour parcours Linux — Basics, Admin, Réseau & Sécurité, Shell & Automation.

#Tags