Planifier une tâche unique avec at, atq et atrm

Vous n'avez pas toujours besoin de cron ou d'un timer systemd. Quand vous devez exécuter une action une seule fois dans 10 minutes, ce soir à 23 h, ou demain matin, at est l'outil le plus direct. Ce guide vous montre le trio at + atq + atrm, avec des sorties mesurées sur Debian 13 et AlmaLinux 10, et les pièges qui font croire qu'une tâche est planifiée alors qu'elle ne s'exécutera jamais.

Ce que vous allez apprendre

• Distinguer les usages de at et cron
• Planifier une commande unique avec at
• Lister la file d'attente avec atq et relire un job avec at -c
• Supprimer une tâche planifiée avec atrm
• Vérifier qu'une tâche a bien tourné
• Éviter les erreurs classiques (service, droits, environnement)

Dans quel contexte ?

at est utile quand une action doit être déclenchée plus tard, mais une seule fois. Le démon atd garde la tâche en file d'attente, l'exécute à l'échéance, puis l'oublie :

• relancer un service hors créneau de production ;
• exécuter un script de nettoyage dans 15 minutes ;
• lancer un contrôle d'intégrité cette nuit ;
• programmer un rappel technique (mail, rapport, rotation).

Alignement certification

Le référentiel RHCSA (EX200, sur RHEL 10) nomme l'outil explicitement : « Schedule tasks using at, cron and systemd timer units ». Le LFCS reste plus général, avec « Manage or schedule jobs for executing commands » dans le domaine Operations Deployment.

at vs cron en 30 secondes

La différence tient en un mot : at exécute une fois, cron répète. Une tâche at disparaît de la file dès qu'elle a tourné, une ligne de crontab reste en place et se redéclenche à chaque échéance.

• Utilisez at pour une exécution ponctuelle.
• Utilisez cron pour une exécution récurrente.

Exemple mental simple :

• "Exécute ce script demain à 09:00" -> at
• "Exécute ce script tous les jours à 09:00" -> cron

Prérequis

Ne présumez pas que at est là : sur une AlmaLinux 10 ou une RHEL 10 minimale, ni le paquet ni l'unité n'existent. Commencez par vérifier l'état du service atd :

# Vérifier que le service atd est actif
systemctl status atd --no-pager

Vous devez voir Active: active (running).

`not-found` n'est pas `disabled`, et l'installation ne suffit pas

Deux surprises se suivent, et elles déroutent le diagnostic.

D'abord, sur une image minimale, systemctl is-enabled atd ne répond pas disabled comme on s'y attendrait, mais not-found : l'unité elle-même n'existe pas, parce que le paquet n'est pas installé.

sudo dnf install -y at      # RHEL, AlmaLinux, Rocky
sudo apt install -y at      # Debian, Ubuntu

Ensuite, l'installation active le service mais ne le démarre pas. Mesuré sur AlmaLinux 10 juste après le dnf install :

Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
Active: inactive (dead)

enabled et pourtant inactive. C'est exactement ce qui fait échouer un critère « le service tourne » alors que tout paraît en ordre. Il faut un démarrage explicite :

sudo systemctl enable --now atd
systemctl is-active atd

Contre-intuitif, et c'est un faux positif classique : avec atd arrêté, la soumission d'une tâche réussit quand même. at accepte le travail, le met en file, et se contente d'un avertissement, mesuré à l'identique sur Debian 13 et AlmaLinux 10 :

warning: commands will be executed using /bin/sh
job 1 at Thu Jul 23 07:36:00 2026
Can't open /run/atd.pid to signal atd. No atd running?

atq liste alors une tâche qui ne s'exécutera jamais. Ne concluez donc jamais de la présence d'une tâche en file que le service est actif : vérifiez systemctl is-active atd séparément.

Étape 1 : planifier une tâche unique avec at

On planifie ici une écriture dans un fichier de sortie. L'option -f lit les commandes dans un fichier plutôt que sur l'entrée standard, et l'expression now + 2 minutes fixe une échéance relative.

mkdir -p /tmp/at-lab
printf '%s\n' 'echo "AT_OK" >> /tmp/at-lab/output.txt' > /tmp/at-lab/job.sh
at -f /tmp/at-lab/job.sh now + 2 minutes

Sortie attendue (exemple) :

warning: commands will be executed using /bin/sh
job 9 at Mon Apr 20 21:24:00 2026

L'avertissement dit /bin/sh, et ce n'est vrai qu'à moitié. Sur Debian et Ubuntu, le job est bien exécuté par /bin/sh, donc par dash. Sur AlmaLinux 10, at -c montre que le corps du job est confié à ${SHELL:-/bin/sh}, c'est-à-dire au shell de l'utilisateur qui a soumis la tâche, souvent bash. Dans les deux cas, le shell n'est pas interactif : vos alias et vos fonctions n'existent pas. Écrivez donc des commandes portables, avec des chemins absolus.

L'heure s'écrit aussi en absolu. Trois comportements mesurés sur Debian 13 et AlmaLinux 10 évitent les mauvaises surprises :

• at 9:00 soumis à 20 h 49 est planifié le lendemain à 9 h, sans avertissement ;
• at 0815 est lu comme 08 h 15, pas comme le 15 août ; écrivez at 09:00 Aug 15 pour une date ;
• at now - 1 hour est refusé avec at: refusing to create job destined in the past.

Étape 2 : inspecter la file avec atq

atq liste les jobs en attente de l'utilisateur courant. C'est le contrôle à lancer juste après une planification, pour vérifier l'heure calculée par at.

atq

Sortie attendue (exemple) :

9       Mon Apr 20 21:24:00 2026 a bob

• première colonne : identifiant du job ;
• date/heure : exécution prévue ;
• lettre a : la file (queue) du job, a par défaut ;
• dernier champ : utilisateur propriétaire.

Pour relire ce qu'un job va réellement exécuter, at -c suivi de l'identifiant affiche le script complet enregistré par at. Il commence par l'environnement capturé au moment de la soumission, puis se termine par vos commandes :

at -c 9 | tail -5

Étape 3 : annuler un job avec atrm

atrm retire un job de la file avant son exécution, en le désignant par l'identifiant lu dans la première colonne d'atq. Relancez atq ensuite pour confirmer la suppression.

# Remplacez 9 par l'identifiant réel
atrm 9
atq

Si la file est vide, atq ne retourne rien.

Étape 4 : vérifier l'exécution quand vous ne supprimez pas le job

Un job exécuté quitte la file : atq ne garde aucun historique. La seule preuve d'exécution est donc l'effet produit par le script, ici une ligne dans le fichier de sortie. Planifiez une tâche et laissez-la s'exécuter :

at -f /tmp/at-lab/job.sh now + 1 minute

Après ~1 minute :

cat /tmp/at-lab/output.txt

Vous devez voir au moins une ligne AT_OK.

Contrôler qui peut utiliser at

Deux fichiers règlent l'accès, sur le même principe que pour cron : /etc/at.allow, s'il existe, est une liste blanche et rend /etc/at.deny sans effet ; sinon, les comptes listés dans /etc/at.deny sont refusés. Un compte bloqué reçoit You do not have permission to use at.

Les valeurs livrées diffèrent. Sur Debian 13 et Ubuntu 24.04, /etc/at.deny liste déjà les comptes système (alias, backup, bin, daemon, ftp...). Sur AlmaLinux 10, il est vide. Dans les deux cas, créer un /etc/at.allow vide interdit at à tous les comptes sauf root (mesuré sur Debian 13).

Bonnes pratiques

Un job at tourne sans personne devant l'écran, dans un environnement réduit : ces règles visent à ce qu'il échoue de façon visible plutôt qu'en silence.

• Utilisez des chemins absolus dans les scripts appelés par at.
• Préférez un script (at -f script.sh) à une commande complexe inline.
• Journalisez la sortie (>> /var/log/... 2>&1) pour faciliter le diagnostic.
• Testez la commande en direct avant de la planifier.

Dépannage rapide

Lisez ce tableau par le symptôme : les trois premières lignes couvrent le cas le plus fréquent, un service atd absent ou arrêté, qui laisse la file se remplir sans que rien ne s'exécute.

Symptôme	Cause probable	Correction
at: command not found	paquet non installé	sudo dnf install at ou sudo apt install at
systemctl is-enabled atd répond not-found	l'unité n'existe pas : le paquet n'est pas installé	installer le paquet, puis enable --now
Le service est enabled mais inactive (dead)	l'installation active sans démarrer	sudo systemctl start atd
Une heure déjà passée est acceptée sans avertissement	at 9:00 soumis l'après-midi est reporté au lendemain	Vérifier avec atq ; un instant explicitement passé (now - 1 hour) est lui refusé
0815 interprété comme 08 h 15, pas le 15 août	forme horaire, pas une date	Écrire la date explicitement (at 09:00 Aug 15)
La sortie de la tâche disparaît	aucun agent de courriel installé (Exec failed for mail command)	Rediriger explicitement vers un fichier dans la commande planifiée
job jamais exécuté	atd inactif	sudo systemctl enable --now atd
job présent mais pas d'effet	script invalide ou PATH incomplet	utiliser chemins absolus, relire le job avec at -c
You do not have permission to use at.	politique at.allow/at.deny	vérifier /etc/at.allow et /etc/at.deny

Glissez pour voir

Mettre en pratique

Planifiez une tâche ponctuelle avec at sur une VM, puis vérifiez qu'elle s'exécute bien à l'heure prévue et que la file est correctement gérée.

Lab guidé Pratique

Apprendre à faire

Planifier une tâche ponctuelle avec at

$ dsoxlab run l3-scheduling-at

Environnement : VM·Durée : ~15 min

Vérification : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start l3-scheduling-at vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run l3-scheduling-at
dsoxlab check l3-scheduling-at

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• at planifie une tâche ponctuelle, atq liste les tâches en attente, atrm en supprime une.
• at -c <id> affiche le script réellement enregistré, environnement compris.
• Le service atd doit être actif : une tâche en file ne prouve rien.
• Le job tourne dans un shell non interactif (/bin/sh sur Debian, le $SHELL de l'utilisateur sur RHEL) : pas d'alias, chemins absolus.
• /etc/at.allow, s'il existe, prime sur /etc/at.deny.
• En contexte admin/certif, at complète cron et les timers.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →