Passer au contenu principal
Linux, OS

Cron et at sous Debian : automatiser sans réveiller l’admin

Bienvenue dans le monde merveilleux des tâches planifiées sous Debian.

Ici, les scripts travaillent pendant que vous dormez, les sauvegardes se déclenchent sans demander la permission et une simple étoile placée au mauvais endroit peut transformer une opération mensuelle en événement se produisant toutes les minutes.

Le principe est pourtant très sain : faire exécuter automatiquement une commande à un moment donné.

Pour cela, deux outils historiques restent particulièrement utiles :

  • cron, pour les tâches récurrentes ;
  • at, pour les tâches ponctuelles à exécuter plus tard.

Et puisque Debian vit désormais très confortablement avec systemd, nous verrons également pourquoi les timers systemd méritent parfois de prendre la relève.

La règle fondamentale :
cron répond à « fais ceci régulièrement ».
at répond à « fais ceci une fois, plus tard ».
systemd timers répondent à « faisons la même chose, mais avec davantage de fichiers de configuration ».

Cron : le démon qui ne dort jamais

cron est un service qui tourne en arrière-plan et examine régulièrement les tâches qui lui ont été confiées.

Lorsque la date et l’heure correspondent à une règle définie dans une crontab, cron exécute la commande associée.

Il ne réfléchit pas à l’opportunité de l’action.

Si vous lui demandez de supprimer un répertoire chaque matin à 3 h 12, il ne vous demandera pas si vous êtes certain. Cron n’est pas votre mère. Cron respecte le planning.

Vérifier que cron fonctionne

Sur un système Debian utilisant le service cron classique :

systemctl status cron

Pour le démarrer :

sudo systemctl start cron

Et pour s’assurer qu’il démarre avec le système :

sudo systemctl enable cron

Sur une installation Debian minimale ou particulière, le paquet peut ne pas être présent. Dans ce cas :

sudo apt install cron

La syntaxe d’une crontab

Dans la crontab personnelle d’un utilisateur, une tâche classique possède cette forme :

* * * * * /chemin/vers/commande

Les cinq champs temporels sont, dans l’ordre :

Position Champ Valeurs courantes
1 Minute 0–59
2 Heure 0–23
3 Jour du mois 1–31
4 Mois 1–12
5 Jour de la semaine 0–7, dimanche étant 0 ou 7

Puis vient la commande à exécuter.

Une étoile signifie :

« Toutes les valeurs possibles pour ce champ. »

Ainsi :

* * * * * /usr/local/bin/script.sh

signifie :

exécuter le script toutes les minutes.

Oui. Toutes.

C’est généralement à ce moment précis que l’on découvre l’importance de relire avant d’enregistrer.

Quelques exemples utiles

Tous les jours à 2 h 30

30 2 * * * /usr/local/bin/backup.sh

Toutes les heures

0 * * * * /usr/local/bin/script.sh

Toutes les cinq minutes

*/5 * * * * /usr/local/bin/check.sh

Chaque lundi à 8 h

0 8 * * 1 /usr/local/bin/report.sh

Le premier jour de chaque mois à minuit

0 0 1 * * /usr/local/bin/monthly.sh

Du lundi au vendredi à 18 h 15

15 18 * * 1-5 /usr/local/bin/cleanup.sh

À 6 h et 18 h chaque jour

0 6,18 * * * /usr/local/bin/sync.sh

Les champs acceptent donc notamment :

  • l’étoile : * ;
  • les listes : 1,3,5 ;
  • les plages : 1-5 ;
  • les pas : */10 ;
  • et certaines combinaisons de ces syntaxes.

Le piège du jour du mois et du jour de la semaine

Cron possède une subtilité suffisamment contre-intuitive pour mériter sa propre section.

Considérez :

0 9 1 * 1 /usr/local/bin/script.sh

On pourrait croire que cela signifie :

« À 9 h, lorsque nous sommes à la fois le premier jour du mois et un lundi. »

Ce n’est pas le comportement du cron classique.

Lorsque le jour du mois et le jour de la semaine sont tous les deux restreints, la tâche est exécutée si l’un ou l’autre correspond.

Cette ligne signifie donc en pratique :

  • à 9 h tous les premiers du mois ;
  • et à 9 h tous les lundis.

C’est une logique OU, pas une logique ET.

Une petite délicatesse historique dont on apprécie pleinement la poésie après avoir lancé un traitement beaucoup plus souvent que prévu.

Les raccourcis pratiques

Cron accepte également plusieurs expressions spéciales qui évitent de sortir les cinq colonnes pour les cas courants.

Expression Signification
@reboot Au démarrage du service cron
@hourly Une fois par heure
@daily Une fois par jour
@midnight Équivalent à @daily
@weekly Une fois par semaine
@monthly Une fois par mois
@yearly Une fois par an
@annually Équivalent à @yearly

Par exemple :

@reboot /usr/local/bin/start-my-thing.sh

Attention toutefois : @reboot signifie que la tâche est lancée lorsque cron démarre. Certains autres services dont votre script dépend peuvent ne pas encore être complètement opérationnels.

Le démarrage d’une machine reste cette période charmante où tout le monde se lève en même temps et prétend être prêt.

Gérer sa crontab

Chaque utilisateur peut posséder sa propre crontab.

Éditer sa crontab

crontab -e

L’afficher

crontab -l

La supprimer entièrement

crontab -r

Cette dernière commande mérite un instant de respect.

Elle ne supprime pas « la ligne qui vous gêne ».

Elle supprime la crontab entière de l’utilisateur.

Pour éviter certains regrets, Debian propose également :

crontab -i -r

qui demande une confirmation avant la suppression.

Administrer la crontab d’un autre utilisateur

Avec les privilèges nécessaires :

sudo crontab -u alice -e

Et pour la consulter :

sudo crontab -u alice -l

Crontab utilisateur et crontab système : attention au champ supplémentaire

Une crontab utilisateur possède :

minute heure jour mois semaine commande

Mais /etc/crontab et les fichiers placés dans /etc/cron.d/ ajoutent un champ indiquant l’utilisateur sous lequel la commande doit être exécutée.

La syntaxe devient alors :

minute heure jour mois semaine utilisateur commande

Par exemple :

30 2 * * * root /usr/local/sbin/backup.sh

C’est important.

Copier directement cette ligne dans la crontab personnelle de root laisserait le mot root au début de la commande.

Cron essaierait alors d’exécuter un programme appelé root.

Il échouerait.

Et quelque part, un administrateur commencerait à soupçonner SELinux alors que SELinux n’est même pas installé.

Les emplacements système sous Debian

Debian utilise plusieurs emplacements traditionnels pour les tâches périodiques.

Emplacement Utilisation
/etc/crontab Crontab générale du système
/etc/cron.d/ Fichiers cron séparés, notamment utilisés par les paquets
/etc/cron.hourly/ Scripts périodiques horaires
/etc/cron.daily/ Scripts quotidiens
/etc/cron.weekly/ Scripts hebdomadaires
/etc/cron.monthly/ Scripts mensuels

Sur une installation Debian classique, ces répertoires sont notamment traités à l’aide de run-parts.

Le piège du nom de fichier dans cron.daily

run-parts applique des règles sur les noms des fichiers qu’il exécute.

Avec son comportement Debian classique, un nom contenant un point peut par exemple être ignoré.

Ainsi :

/etc/cron.daily/backup

est un bon nom.

Alors que :

/etc/cron.daily/backup.sh

peut ne pas être sélectionné par run-parts avec ses règles par défaut.

Le script est là. Il est exécutable. Vous le regardez depuis quarante minutes.

Mais son extension .sh lui a valu une condamnation administrative sans procès.

Pour voir ce que run-parts considère comme exécutable :

run-parts --test /etc/cron.daily

Les permissions comptent

Un script planifié doit évidemment être accessible et exécutable par l’utilisateur qui lance la tâche.

Par exemple :

sudo chmod 750 /usr/local/sbin/backup.sh

Mais la sécurité ne se limite pas au bit d’exécution.

Un script lancé par root ne doit pas être modifiable par n’importe quel utilisateur.

Imaginez :

0 2 * * * root /opt/scripts/backup.sh

Si backup.sh est modifiable par un utilisateur non privilégié, celui-ci dispose essentiellement d’un rendez-vous quotidien avec root à 2 h du matin.

Une relation professionnelle à éviter.

L’environnement cron : « pourtant ça fonctionne dans mon terminal »

C’est probablement le problème le plus classique avec cron.

Vous exécutez :

/home/alice/scripts/report.sh

dans votre terminal.

Tout fonctionne.

Vous ajoutez le même script dans cron.

Plus rien.

Vous vérifiez le fichier.

Vous vérifiez l’heure.

Vous commencez à remettre en cause le concept même du temps.

La raison est souvent simple : cron ne dispose pas nécessairement du même environnement que votre session interactive.

Il peut notamment avoir :

  • un PATH différent ;
  • aucun environnement virtuel Python activé ;
  • aucune variable chargée depuis votre .bashrc ;
  • un shell différent de celui que vous utilisez habituellement ;
  • un répertoire de travail différent de celui que votre script suppose.

Utilisez des chemins absolus

Au lieu de :

0 2 * * * python backup.py

préférez quelque chose comme :

0 2 * * * /usr/bin/python3 /home/alice/scripts/backup.py

Et si le script dépend d’un répertoire particulier :

0 2 * * * cd /home/alice/app && /usr/bin/python3 backup.py

Définir explicitement PATH

Une crontab peut aussi contenir des variables d’environnement :

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

30 2 * * * /usr/local/bin/backup.sh

Définir ce dont la tâche dépend rend son comportement beaucoup plus prévisible.

Les scripts automatisés apprécient particulièrement qu’on ne leur demande pas de deviner.

Le caractère % : le petit piège sadique

Dans une crontab traditionnelle, le caractère % possède une signification spéciale lorsqu’il apparaît dans la partie commande.

Un pourcentage non échappé peut être transformé en saut de ligne, et la suite peut être envoyée à l’entrée standard de la commande.

Cela peut surprendre avec une commande comme :

date +%Y-%m-%d

Dans une crontab, il faut donc généralement échapper les pourcentages :

0 0 * * * /usr/bin/date +\%Y-\%m-\%d

Voilà une fonctionnalité historique que presque personne ne demande et que beaucoup découvrent exactement une fois.

Où vont les sorties de cron ?

Une tâche produit souvent deux flux :

  • stdout : la sortie normale ;
  • stderr : les erreurs.

Traditionnellement, cron peut envoyer cette sortie par e-mail à l’utilisateur si un système de messagerie local est configuré.

Sur beaucoup de machines modernes, aucun MTA local complet n’est configuré.

Résultat : votre script crie dans une pièce insonorisée.

Rediriger vers un fichier

0 3 * * * /usr/local/bin/script.sh >> /var/log/script.log 2>&1

Ici :

  • >> ajoute stdout au fichier ;
  • 2>&1 envoie également stderr vers la même destination.

Ou envoyer vers le journal système

On peut aussi utiliser logger :

0 3 * * * /usr/local/bin/script.sh 2>&1 | /usr/bin/logger -t mon-script

Puis rechercher les messages :

journalctl -t mon-script

Déboguer cron quand il fait semblant de ne pas vous connaître

Lorsqu’une tâche ne fonctionne pas, procédez méthodiquement.

1. Vérifier le service

systemctl status cron

2. Examiner le journal

Sur un système avec systemd :

journalctl -u cron

Pour suivre les nouvelles entrées en direct :

journalctl -u cron -f

Si rsyslog est installé et configuré de manière classique, les événements cron peuvent également apparaître dans :

/var/log/syslog

Un fichier comme :

/var/log/cron.log

n’existe pas nécessairement par défaut : cela dépend de la configuration de la journalisation.

3. Exécuter la commande manuellement

/usr/local/bin/script.sh

Idéalement sous le même utilisateur que cron :

sudo -u alice /usr/local/bin/script.sh

4. Vérifier les permissions

ls -l /usr/local/bin/script.sh

5. Vérifier l’interpréteur

Un script devrait généralement posséder un shebang correct :

#!/bin/bash

ou :

#!/usr/bin/env python3

6. Vérifier les chemins

Ne partez pas du principe que cron trouvera automatiquement vos programmes, vos fichiers de configuration et votre environnement virtuel.

Cron n’a rien contre vous personnellement.

Il ne sait simplement pas que vous aviez ajouté douze choses à votre .bashrc.

Cron et les machines éteintes

Un point essentiel : cron classique n’est pas une machine à remonter le temps.

Si vous planifiez :

0 3 * * * /usr/local/bin/backup.sh

et que l’ordinateur est éteint à 3 h, la tâche n’est généralement pas exécutée rétroactivement lorsque la machine redémarre à 9 h.

Le rendez-vous est passé.

Cron était là.

Votre ordinateur non.

Le dossier est classé.

Anacron : pour les machines qui dorment

C’est précisément le problème que cherche à résoudre anacron.

Anacron est destiné aux tâches périodiques exprimées plutôt en jours qu’en minutes et ne suppose pas que la machine fonctionne en permanence.

Il peut donc être utile sur :

  • un ordinateur portable ;
  • une station de travail éteinte la nuit ;
  • un serveur qui n’est pas opérationnel 24 h/24 ;
  • ou toute machine ayant l’audace de dormir à l’heure où vous aviez prévu la maintenance.

Sa configuration traditionnelle se trouve dans :

/etc/anacrontab

Une ligne comprend notamment :

période délai identifiant commande

Par exemple, conceptuellement :

1 5 sauvegarde-quotidienne /usr/local/bin/backup.sh

signifie qu’une tâche doit être exécutée environ une fois par jour, avec le délai prévu lorsqu’anacron constate qu’elle est due.

Sur Debian, anacron peut également prendre en charge les travaux quotidiens, hebdomadaires et mensuels qui seraient autrement lancés par cron.

Cron dit : « Il fallait être là à 3 h. »
Anacron dit : « Vous avez raté 3 h, mais nous devons tout de même faire cette sauvegarde. »

Anacron est donc le collègue qui rattrape le travail oublié.

Personne ne l’aime jusqu’au jour où il devient indispensable.

Sécuriser cron

Une tâche automatisée possède exactement les droits de l’utilisateur qui l’exécute.

Une tâche root possède donc les droits de root.

Cette phrase devrait normalement suffire à provoquer un léger redressement sur votre chaise.

Quelques règles simples

  • ne lancez pas en root ce qui peut fonctionner avec un compte moins privilégié ;
  • utilisez des scripts dont les permissions sont maîtrisées ;
  • évitez les répertoires modifiables par tout le monde ;
  • utilisez des chemins absolus ;
  • ne placez pas de secrets directement dans une ligne de crontab lorsque cela peut être évité ;
  • contrôlez les fichiers et données que le script va traiter ;
  • journalisez les erreurs importantes ;
  • et ne téléchargez pas un script nommé totally-safe-backup.sh sur un forum abandonné avant de le lancer chaque nuit en root.

cron.allow et cron.deny

Debian prend en charge :

/etc/cron.allow
/etc/cron.deny

Si /etc/cron.allow existe, seuls les utilisateurs autorisés par ce fichier peuvent utiliser crontab.

Sinon, /etc/cron.deny peut servir à interdire certains utilisateurs.

Sur un système Debian standard, les utilisateurs peuvent normalement utiliser crontab en l’absence de restrictions spécifiques.

Ces fichiers contrôlent principalement l’utilisation de la commande crontab. Ils ne constituent pas une baguette magique annulant nécessairement les tâches déjà installées.

at : « fais ça une fois, plus tard »

at répond à un besoin différent.

Vous ne voulez pas exécuter quelque chose tous les jours.

Vous voulez simplement dire :

« Exécute cette commande dans dix minutes, puis ne m’en reparle plus. »

C’est exactement le rôle d’at.

Installer at sous Debian

Le paquet n’est pas nécessairement installé :

sudo apt install at

Les tâches sont exécutées par le démon atd.

Vérifiez-le avec :

systemctl status atd

Et si nécessaire :

sudo systemctl enable --now atd

Sans atd, vous pouvez remplir la file de tâches avec tout l’enthousiasme du monde : personne ne viendra les exécuter.

Programmer une tâche avec at

Dans dix minutes

echo "/home/alice/script.sh" | at now + 10 minutes

Aujourd’hui à 15 h

at 15:00

at ouvre alors une invite interactive :

warning: commands will be executed using /bin/sh
at> /home/alice/script.sh
at> <Ctrl+D>

Ctrl+D termine la saisie et enregistre la tâche.

Demain après-midi

at 3pm tomorrow

À minuit

at midnight

Dans deux heures

at now + 2 hours

Les syntaxes temporelles acceptées sont relativement souples.

Une qualité appréciable lorsque l’on programme une tâche unique et légèrement inquiétante.

Voir les tâches at en attente

atq

Une sortie peut ressembler à :

7   Sat Aug 22 15:00:00 2026 a alice
8   Sat Aug 22 18:30:00 2026 a alice

Le premier nombre est l’identifiant du job.

Supprimer une tâche at

atrm 7

Le job numéro 7 disparaît de la file.

Il n’aura jamais lieu.

Une petite branche temporelle vient de s’éteindre, et personne ne saura jamais ce que script.sh comptait faire à 15 h.

Inspecter une tâche at

Pour afficher le contenu d’un job :

at -c 7

C’est particulièrement utile lorsqu’on se retrouve devant une tâche programmée trois semaines auparavant avec un identifiant qui ne rappelle absolument rien.

at et son environnement

Lorsqu’un job est soumis avec at, l’outil conserve une partie de l’environnement du moment où la tâche a été créée.

Mais comme avec cron, il reste prudent de concevoir des tâches autonomes :

  • utiliser des chemins absolus ;
  • ne pas dépendre d’un terminal interactif ;
  • rediriger les sorties si nécessaire ;
  • s’assurer que les fichiers existeront encore au moment de l’exécution.

Une tâche programmée pour demain qui dépend d’un fichier temporaire supprimé ce soir possède ce que l’on appelle techniquement un avenir compliqué.

Les sorties des tâches at

at peut envoyer la sortie du job par courrier local.

Là encore, cela suppose qu’un système de messagerie local puisse effectivement distribuer ce courrier.

Pour une journalisation explicite :

echo "/home/alice/script.sh >> /home/alice/script.log 2>&1" | at 23:00

Ou vers le journal système :

echo "/home/alice/script.sh 2>&1 | logger -t at-script" | at 23:00

Contrôler qui peut utiliser at

Deux fichiers remplissent ce rôle :

/etc/at.allow
/etc/at.deny

Le principe est le suivant :

  • si /etc/at.allow existe, seuls les utilisateurs qui y figurent peuvent utiliser at ;
  • sinon, si /etc/at.deny existe, tous les utilisateurs sauf ceux qui y figurent peuvent l’utiliser ;
  • un /etc/at.deny vide autorise donc tous les utilisateurs ;
  • si aucun des deux fichiers n’existe, l’implémentation Debian d’at réserve normalement son utilisation au superutilisateur.

Root conserve évidemment ses privilèges.

Root conserve toujours ses privilèges.

C’est en partie pour cela que root est rarement invité aux activités de groupe.

Et batch ? Le cousin discret d’at

Le paquet at fournit également la commande batch.

Elle permet de mettre une commande en attente afin qu’elle soit exécutée lorsque la charge du système descend suffisamment.

Par exemple :

echo "/usr/local/bin/heavy-job.sh" | batch

C’est utile pour certains travaux lourds qui ne sont pas urgents.

Au lieu de dire :

« Lance ça à 14 h. »

on dit :

« Lance ça lorsque la machine arrêtera de souffrir. »

Une forme primitive mais néanmoins respectable d’empathie envers le processeur.

Cron ou at ?

Besoin Outil
Exécuter une tâche tous les jours cron
Exécuter une tâche tous les lundis cron
Exécuter une tâche toutes les cinq minutes cron
Exécuter une commande une fois dans dix minutes at
Exécuter quelque chose une seule fois demain at
Attendre une charge système suffisamment faible batch
Rattraper des tâches périodiques après une extinction anacron ou timer systemd persistant

Et systemd timers dans tout ça ?

Sur un Debian moderne, il serait dommage de parler d’automatisation sans mentionner les timers systemd.

Ils remplissent une partie des mêmes fonctions que cron, mais avec une intégration plus profonde à systemd.

Un timer est généralement associé à un service.

Par exemple :

/etc/systemd/system/backup.service

pour décrire ce qu’il faut exécuter, et :

/etc/systemd/system/backup.timer

pour indiquer quand l’exécuter.

Exemple de service

[Unit]
Description=Sauvegarde quotidienne

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Exemple de timer

[Unit]
Description=Lance la sauvegarde quotidienne

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Puis :

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Afficher les timers

systemctl list-timers

Examiner les journaux

journalctl -u backup.service

Pourquoi utiliser un timer systemd ?

Les timers apportent plusieurs avantages intéressants :

  • journalisation naturellement intégrée à journalctl ;
  • dépendances explicites envers d’autres services ;
  • limitation et isolation possibles via les options systemd ;
  • planification calendaire ou relative au démarrage ;
  • possibilité de répartir les exécutions avec des délais aléatoires ;
  • et possibilité de rattraper certaines exécutions manquées.

Persistent=true : rattraper le rendez-vous manqué

Avec :

Persistent=true

un timer basé sur OnCalendar= peut détecter qu’une exécution aurait dû se produire pendant que le timer ou la machine était inactif et déclencher le service au retour.

C’est une différence importante avec une tâche cron classique.

Cron :

« Il fallait être allumé à 2 h 30. »

Timer systemd persistant :

« Vous avez raté la sauvegarde de 2 h 30. On s’en occupe maintenant. »

L’un est ponctuel.

L’autre garde les dossiers.

Cron ou timer systemd ?

Il n’est pas nécessaire de déclarer une guerre de religion supplémentaire.

Cron reste parfaitement adapté à beaucoup de tâches simples :

0 2 * * * /usr/local/bin/backup.sh

C’est court, lisible et connu de presque tous les administrateurs Unix.

Un timer systemd devient particulièrement intéressant lorsque vous avez besoin :

  • de dépendances entre services ;
  • d’une journalisation centralisée ;
  • d’un contrôle précis de l’environnement d’exécution ;
  • d’une politique de sécurité systemd ;
  • de rattraper les exécutions manquées ;
  • ou d’une tâche suffisamment importante pour mériter une unité dédiée.

Pour lancer un petit script chaque nuit, cron reste très élégant.

Pour orchestrer un service critique avec dépendances, reprise, restrictions et journalisation structurée, systemd offre davantage de leviers.

Utiliser quinze lignes de systemd pour exécuter touch /tmp/test une fois par jour reste cependant autorisé.

La loi ne peut pas tout empêcher.

Quelques erreurs classiques à éviter

« Mon script marche en terminal mais pas dans cron »

Vérifiez le PATH, les variables d’environnement, le shell, le répertoire courant et les permissions.

« J’ai mis mon script dans cron.daily et il ne démarre jamais »

Vérifiez notamment :

run-parts --test /etc/cron.daily

et le nom du fichier.

« Ma tâche du premier lundi s’exécute tous les lundis ET le premier du mois »

Vous venez de rencontrer la logique particulière entre les champs « jour du mois » et « jour de la semaine ».

« Ma commande contenant date +%F ne fonctionne pas »

Échappez le caractère % dans la crontab.

« Ma tâche quotidienne n’a pas tourné cette nuit »

La machine était-elle allumée à l’heure prévue ?

Sinon, intéressez-vous à anacron ou aux timers systemd persistants.

« at accepte ma tâche mais rien ne se passe »

Vérifiez :

systemctl status atd

Une file d’attente sans démon pour la traiter est essentiellement une liste de souhaits.

Une méthode raisonnable avant d’automatiser

Avant de confier une commande au temps lui-même :

  1. exécutez-la manuellement ;
  2. exécutez-la avec le bon utilisateur ;
  3. utilisez des chemins absolus ;
  4. vérifiez les permissions ;
  5. décidez où doivent aller stdout et stderr ;
  6. évitez deux exécutions simultanées si le script ne les supporte pas ;
  7. testez les conséquences d’un échec ;
  8. et seulement ensuite, planifiez-la.

Pour les tâches critiques, il faut également se demander ce qui se passe si l’exécution précédente n’est pas terminée lorsque la suivante commence.

Une sauvegarde prévue toutes les dix minutes qui dure quinze minutes finit par produire une forme très particulière d’élevage intensif de processus.

Éviter les exécutions simultanées avec flock

Une solution simple consiste à utiliser flock.

Par exemple :

*/10 * * * * /usr/bin/flock -n /run/user/1000/mon-script.lock /home/alice/script.sh

L’option -n demande à flock d’abandonner immédiatement si le verrou est déjà détenu.

Pour une tâche système exécutée avec un autre utilisateur, choisissez évidemment un emplacement de verrou approprié et accessible à cet utilisateur.

Le principe est simple : une seule copie du travail à la fois.

Une règle que les réunions auraient également intérêt à adopter.

Résumé

Outil Usage principal À retenir
cron Tâches récurrentes Simple, historique, efficace
at Tâche unique dans le futur Nécessite le service atd
batch Tâche différée selon la charge Fourni avec at
anacron Tâches périodiques sur machines non permanentes Peut rattraper des travaux quotidiens ou périodiques
systemd timer Planification moderne intégrée à systemd Logs, dépendances, options de sécurité et persistance

Conclusion : automatiser, puis surveiller l’automatisation

La planification de tâches est l’une des fonctions les plus utiles d’un système Unix.

cron permet d’exécuter des traitements récurrents depuis des décennies avec une syntaxe compacte et relativement simple.

at s’occupe des actions ponctuelles.

anacron vient au secours des machines qui n’ont pas eu la courtoisie de rester allumées.

Et les timers systemd apportent une approche plus moderne, plus intégrée et parfois mieux adaptée aux services importants.

Mais automatiser une commande ne signifie pas qu’on peut ensuite oublier son existence.

Une sauvegarde automatique qu’on ne contrôle jamais est simplement une croyance.

Un script automatique sans logs est un suspect sans casier.

Et une crontab root modifiée un vendredi soir est généralement le début d’une histoire racontée le lundi avec beaucoup moins d’enthousiasme.

Automatisez donc.

Journalisez.

Surveillez.

Et avant d’enregistrer une ligne contenant cinq étoiles, recomptez-les.

Le temps est impitoyable. Cron aussi.

Post Views: 26