Planifier des tâches pour l'ordinateur
De Wiki de la communauté Mandriva.
Que peut faire la planification ?
Vous êtes derrière votre PC Linux, en train de pianoter gaiement (ou en pestant afin de résoudre un problème bizarre ;-)), lorsque soudainement votre disque dur se met à fonctionner et que votre système manifeste des signes d'activité. Quelques minutes plus tard, cette activité s'arrête et tout redevient comme avant. Vous venez tout simplement d'observer l'exécution d'une tâche planifiée, ou d'un job. En termes Unix, un Job est un programme fonctionnant à l'arrière plan (background en anglais), c'est-à-dire sans nécessiter l'intervention d'un utilisateur.
Mandriva Linux est livrée avec quelques tâches planifiées qui réalisent des actions de maintenance : mise à jour de la base de données pour la commande locate par le programme updatedb, gestion des fichiers de logs (journaux) dans le répertoire /var/log (le programme logrotate assure une rotation des fichiers pour maîtriser l'espace disque consommé), vérification de la sécurité (notamment par le programme msec), suppression de la mémoire système des modules non utilisés, etc. Si vous êtes curieux, regardez les répertoires /etc/cron.d, /etc/cron.hourly (tâches effectuées toutes les heures), /etc/cron.daily (tâches effectuées chaque jour), /etc/cron.weekly (tâches effectuées toutes les semaines) et /etc/cron.monthly (tâches effectuées tous les mois) : ils contiennent les scripts qui sont exécutés par le service crond ou par anacron, en général sous l'autorité du fichier /etc/crontab. Nous reviendrons plus bas sur tout cela.
Bien sûr, vous pouvez aussi profiter vous-même des avantages de ce système, par exemple pour :
- faire des sauvegardes régulièrement
- configurer le système pour qu'il aille chercher les mails toutes les heures
- vous envoyer à vous-même des messages de type « agenda »
- envoyer des mails d'anniversaire aux bonnes personnes à la bonne date
- supprimer des fichiers temporaires ou des fichiers non utilisés
- planifier des téléchargements, des mises à jour de miroirs
- déconnecter les utilisateurs inactifs
- éteindre votre ordinateur
- etc.
En résumé : toute action régulière qui ne nécessite pas d'action directe de la part d'un utilisateur peut être réalisée par votre système Mandriva Linux.
Les quatre commandes suivantes permettent de planifier l'exécution de diverses tâches :
- sleep suspend l'exécution d'un job pour une durée donnée
- at lance un job à un certain moment
- cron lance des jobs à intervalles réguliers
- anacron lance des jobs suivant des critères plus souples en tenant compte de l'extinction éventuelle de la machine.
En outre :
- KAlarm permet de gérer des tâches par l'interface graphique de KDE.
Nous examinerons ici tour à tour ces différents outils.
La commande sleep est toujours disponible sur un système Linux, car elle est souvent utilisée dans les scripts shell. Les paquetages at et cronie-anacron pourraient ne pas être installés (vérifiez avec rpm -q at et rpm -q cronie-anacron). cron est inclus dans l'installation standard (paquetage cronie).
Pour planifier une tâche unique : les commandes sleep et at
La commande sleep
La commande sleep est toujours disponible sur un système Linux, car elle est souvent utilisée dans les scripts shell.
À moins que vous n'écriviez vos propres scripts (ou que vous modifiiez des scripts existants), sleep présente un intérêt relativement limité. Dans les scripts, cependant, cette commande joue un rôle important. Sa syntaxe est :
sleep nombre [smhd]
L'unité par défaut est la seconde (s). On peut spécifier un nombre de minutes (sleep 2m), un nombre d'heures (sleep 3h) ou un nombre de jours (sleep 7d).
Exemple : un rappel par fenêtre surgissante
Vous disposez encore de 10 minutes avant de partir. Vous voulez que Linux vous le rappelle.
Entrez cette commande dans un terminal (ou dans le champ ligne de commande d'une fenêtre appropriée de votre gestionnaire de fenêtres) :
(suppose d'avoir installé sur votre machine le paquetage xmessage)
Une fenêtre d'avertissement s'affichera sur votre bureau dans 10 minutes.
Les commandes sleep et xmessage sont, comme il est normal, enchaînées par un point-virgule. Mettre l'ensemble des deux commandes entre parenthèses en fait un « bloc de code » qui sera globalement exécuté à l'arrière-plan grâce à l'esperluette (&) finale, ce qui vous permettra de garder entretemps l'usage de votre console pour d'autres commandes éventuelles.
D'autres moyens de faire apparaître un message sur le bureau à un moment donné seront indiqués à la section KAlarm.
Planifier l'arrêt de l'ordinateur
Quand je suis au lit, le soir, je tiens parfois à me laisser la possibilité de revenir à l'ordinateur sans avoir à tout relancer, mais je ne veux pas pour autant que ma machine reste allumée toute la nuit si je m'endors avant de penser à l'éteindre. Je peux alors taper ceci sur une console (et cela devrait marcher, sur la Mandriva, même en étant connecté comme simple utilisateur) :
et dans une heure et demie (90 minutes), alors que je serai plongé dans mes rêves, l'ordinateur s'éteindra de lui-même...
Si d'aventure la commande halt n'est accessible que sous root sur votre système, rappelez-vous que vous pouvez la rendre accessible à un simple utilisateur en configurant sudo. Voir root#Un su plus facile à manipuler : sudo.
La commande at
A quoi sert at ?
La commande at sert à planifier l'exécution d'une tâche (ou « job ») qui sera lancée une seule fois, à un moment que vous aurez choisi. Si l'ordinateur est éteint à ce moment-là, le job sera exécuté au démarrage de la machine.
Activer at
A partir de la console
at ajoutera le « job » qu'il a créé à une file d'attente des tâches planifiées, entreposée dans le répertoire /var/spool/at et gérée par atd, le démon de at (chaque tâche est un fichier texte, que vous pouvez parfaitement lire sous root, si le cœur vous en dit). Le démon atd doit donc être activé pour que la commande at fonctionne correctement. Vous pouvez le vérifier, sous root, en tapant ceci en console :
si atd est activé, vous obtiendrez un affichage de ce type :
atd (pid xxxx) est en cours d'exécution...
Sinon, lancez-le ainsi :
A partir de l'interface graphique de Mandriva
Vous pouvez aussi vérifier l'activation de atd par l'interface graphique en lançant le Centre de Contrôle de Mandriva (taper mcc en console sous root, ou bien cliquer sur l'icône Configurer votre ordinateur, puis faites : Système > Gérer les services système). Si atd est activé, il doit être marqué comme actif...
Comment planifier une tâche ?
Indiquer le moment de l'exécution souhaitée
Voyons maintenant, pour commencer, comment il est possible d'indiquer à atd le moment où la tâche programmée devra être exécutée.
Vous pouvez donner à at une date précise, comme « le 20 septembre 2007 à midi cinq » :
mais vous pouvez aussi lui donner une date relative (définie par rapport au « présent », c'est-à-dire par rapport au moment où vous lancez la commande at) comme « demain à 14 heures » :
- tomorrow signifie « demain » en anglais - notez que 2pm sera « 2 h de l'après-midi » et 2am « 2h du matin » - bien entendu « à 14 heures (aujourd'hui) » pourra s'exprimer ainsi :
ou, de façon équivalente mais beaucoup plus naturelle dans le monde francophone :
comme vous le voyez, il y a souvent plus d'une façon, pour at, de dire la même chose… Mais attention, les jobs définis par l'une ou l'autre des deux commandes at qui précèdent seront exécutés dès que l'horloge marquera 14 heures, le jour même, par conséquent, si la commande est lancée avant 14 h, mais ils seront exécutés le lendemain si la commande est lancée après 14h… bien entendu.
Pour exprimer « dans 5 heures et 25 minutes », s'il est 16 heures au moment où l'on tape la commande, on écrira :
dans des cas de ce genre on utilisera donc hours pour « heures », minutes pour… bon, days pour « jours », months pour « mois » (notez que at ne descend pas en dessous de la minute et ne sait pas compter en secondes...).
Le s du pluriel reste nécessaire même pour l'unité (on écrira donc « + 1 minutes » ou « + 1 hours » etc.).
Mais, dans de tels cas, on peut aussi parfois utiliser plus simplement une forme now + … (now signifie « maintenant » en anglais), « dans cinq minutes » se dira alors :
Noter cependant qu'on ne peut écrire, pour « dans 5 heures et 5 minutes », quelque chose comme now + 5 hours + 5 minutes : on ne peut avoir qu'un seul argument additif.
Outre les mots clé tomorrow et now, que nous avons vus, ou today que nous verrons plus bas, at permet aussi l'utilisation de midnight pour « minuit » et noon pour « midi » et même teatime (l'heure du thé..) pour 16 h !
La liste des options valides est disponible dans le fichier /usr/share/doc/at/timespec.
Comment ajouter une tâche au 'planning'
Première méthode
Pour ajouter un job à la file gérée par at, voici quelle est la procédure usuelle :
|
Ce que vous ferez aura la forme générale suivante (avec les messages produits en réponse par at) :
at heure date <ENTREE> warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh'' at> commande_1<ENTREE> at> commande_2<ENTREE> ... at> <CTRL d> job <numéro_du_job> at <date> <heure>
Par exemple, effacer un fichier et en déplacer un autre, donnera quelque chose comme ceci :
warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh
at> /bin/rm -f /home/toto/Documents/gros_fichier.txt
at> /bin/mv /home/toto/archive1.txt /home/toto/Documents/
at> <EOT>
job 1 at Thu Jun 28 23:10:00 2012
(<EOT> apparaît sur la console quand vous tapez <Ctrl d> pour arrêter la liste des commandes à exécuter ; l'ensemble des commandes à exécuter au même moment sont considérées comme un seul job associé à un numéro de job unique)
L'édition des commandes est un peu pénible avec la méthode que nous venons de décrire :
- on ne dispose pas de la complétion automatique (taper le début d'une commande puis <TAB> pour que le reste de la commande se complète automatiquement)
- on ne dispose pas de l'expansion des noms de fichiers (caractères * pour remplacer un suite quelconque de caractères, caractère ? pour remplacer un caractère quelconque, les crochets [...] pour remplacer un caractère appartenant à un ensemble particulier)
- on ne peut naviguer dans la commande avec la touche <Flèche gauche>.
La seconde méthode - décrite ci-dessous - contourne toutes ces difficultés.Seconde méthode
Il est également possible de passer une commande à at par l'intermédiaire d'un tube. Ainsi, pour éteindre votre ordinateur dans une demie-heure en lançant la commande halt, vous pouvez taper en console (sous votre identité de simple utilisateur) :
Vous pouvez aussi combiner des commandes de cette façon ; l'exemple suivant videra à 15h le dossier Téléchargements et y créera ensuite un fichier vide nommé horodatage :
Avec cette méthode l'édition des commandes est plus aisée qu'avec la méthode précédente : on peut, à tout moment, circuler dans la ligne en cours de frappe avec les flèches gauche et droite, on peut utiliser l'expansion des noms de fichiers (caractères *, ?, crochets [...]) et si l'on prend soin de taper les commandes avant de les enclore dans des guillemets, on peut aussi disposer de la complétion automatique.
Obtenir des informations sur les tâches actuellement prévues
Si l'une des commandes produit une sortie console, la commande at vous la transmettra par mail, si du moins vous avez pris soin de configurer votre Mail local. En revanche aucune sortie n'apparaîtra sur la console où vous avez lancé la commande at.
Pour connaître la liste des jobs en attente dans la file, avec leur numéro de job et leur date et heure d'exécution prévue, exécutez :
Pour voir le contenu de la commande correspondant à un certain job, tapez :
Supprimer une tâche
Pour supprimer un job de la liste, utilisez :
Utiliser un fichier contenant des commandes à fournir à at
Notez enfin que si vous utilisez fréquemment at avec une même ligne de commande complexe (comprenant par exemple plusieurs commandes enchaînées ou des adresses compliquées) vous pouvez mettre cette ligne de commande dans un fichier et appeler at avec l'option -f qui permet à at de lire la commande incluse dans le fichier indiqué après l'option :
Exemple 1 : s'envoyer à soi-même un message de rappel.
Vous devez passer un coup de fil important dans 3 jours à 16 heures. Vous pouvez demander à at de vous envoyer un message une demi-heure avant (votre système de mail local doit être configuré correctement pour que vous receviez le message automatiquement) :
at> echo 'Coup de fil à passer à 16 heures !!' | mail votre_nom@localhost
at> <CTRL>+<d>
N'oubliez pas que s'il est plus de 15h 30 au moment où vous écrivez la commande, at commencera à compter à partir du lendemain à 15h 30 et vous recevrez votre message un jour trop tard !
Nota : Le tube | mail votre_nom@localhost n'est normalement pas nécessaire : le message sera automatiquement expédié vers votre compte de mail local.
Exemple 2 : chercher dans quels fichiers on trouve le nom de votre meilleure amie et faire ensuite une sauvegarde avec Unison
at> find /home/toto/Documents -type f -exec grep -l 'Marie Val' {} \; 2>/dev/null
at> unison -batch doc
at> <CTRL>+<d>
Dans une heure (now + 1 hours), la liste des noms des fichiers contenant « Marie Val » sera construite puis envoyée à votre mail local. Et une sauvegarde Unison en mode silencieux (batch) utilisant le profil Unison doc.prf sera lancée : vous en trouverez aussi un compte-rendu dans votre mail local.
Exemple 3 : planifier l'arrêt de l'ordinateur
Vous pourrez télécharger, en cliquant sur les liens ci-dessous, les scripts de FuRex qui permettent de planifier l'arrêt de l'ordinateur à un moment de votre choix.
Ces scripts font appel à at.
- le script zzz qui planifie l'arrêt
- le script zzzstop qui permet d'annuler l'arrêt prévu par zzz.
En raison d'une imperfection du Wiki les noms de ces scripts tels que vous les téléchargerez commencent par une majuscule et doivent posséder une extension (.sh). Pour une utilisation plus confortable, commencez par les renommer ainsi : Zzz.sh -> zzz et Zzzstop.sh -> zzzstop.
Comment tenir compte de la charge du système avec la commande batch
L'outil batch fait partie du paquetage at. Les jobs at invoqués par batch sont exécutés si la charge du système est inférieure à 0.8 (vous pouvez obtenir la charge du système à un moment donné - load average en anglais - en invoquant la commande uptime). Cette valeur peut être changée ainsi :
atd -l valeur
La commande batch s'utilise comme at à ceci près qu'on ne lui fournit ni heure ni date. Une utilisation de batch peut donc avoir la forme générale suivante :
warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh
at> commande_1<ENTREE>
at> commande_2<ENTREE>
at> <CTRL d>
job <nombre> at <date> <heure>
Ou :
Les commandes sont exécutées les unes après les autres dès que la charge du système tombe sous la limite imposée.
at, batch et la sécurité
La configuration par défaut autorise tous les utilisateurs à utiliser at et batch. Pour exclure certains utilisateurs, il suffit d'ajouter leur nom d'utilisateur dans le fichier /etc/at.deny. Il est aussi possible de spécifier tous les utilisateurs autorisés en ajoutant leur nom d'utilisateur dans le fichier /etc/at.allow (par défaut, ce fichier n'existe pas, vous devrez le créer si vous souhaitez déterminer une liste exclusive d'utilisateurs licites de at).
Pour des raisons de sécurité, il peut arriver que le service atd soit désactivé : dans la Mandriva, c'est l'option par défaut (qui reste cependant modifiable) pour le niveau de sécurité secure de l'utilitaire de gestion de la sécurité msec, et aussi lorsque l'administrateur a complètement désactivé msec.
Pour désactiver ou activer at et batch, ouvrir l'interface de msec : msecgui et modifier le champ Valeur de Paramètres de sécurité > Sécurité du système > ALLOW_AT_CRONTAB.
Planifier l'exécution régulière d'une tâche : le démon crond
Introduction
À proprement parler, il n'existe pas de programme cron mais simplement un démon crond, qui est lancé automatiquement au démarrage du système.
crond fait donc partie des services du système.
Il existe aussi une commande crontab qui permet à crond de manipuler les fichiers de configuration de crond. Ces fichiers de configuration sont connus sous l'appellation de crontab.
Des outils graphiques existent pour gérer cron.
Depuis longtemps, Webmin (paquetage Mandriva webmin) propose des modules pour configurer le service crond via une interface graphique.
Sous KDE, vous pourrez faire usage de Configuration du Système > Planificateur de tâches.
Une bonne connaissance des soubassements de cron décrits dans ce qui suit vous aidera néanmoins, même si vous utilisez ces outils.
Le système crontab, dans Mandriva Linux, comprend deux parties.
1. L'ensemble des tâches crond du système est contrôlé, pour l'essentiel, par le fichier de configuration /etc/crontab.
Sous Mandriva, ce fichier détermine le lancement à intervalles réguliers du programme /usr/bin/run-parts (sur ce programme voir plus bas #La commande run-parts). Ce dernier appelle à son tour les scripts stockés dans les répertoires /etc/cron.hourly (tâches à effectuer toutes les heures), /etc/cron.daily (tâches à effectuer tous les jours), /etc/cron.weekly (tâches à effectuer toutes les semaines) et /etc/cron.monthly (tâches à effectuer tous les mois).
Les tâches peuvent être effectuées sous l'identité d'un utilisateur spécifié. Plus de détails sur cette crontab et sur les façons de la modifier seront fournis plus bas.
Des crontab analogues à /etc/crontab peuvent aussi être placées dans le répertoire /etc/cron.d. Par défaut, ce répertoire est vide.
2. les fichiers crontab des utilisateurs (y compris root) sont stockés dans le répertoire /var/spool/cron/. Ils lancent des tâches sous l'identité d'un utilisateur particulier. Ils portent le nom de l'utilisateur : /var/spool/cron/toto, /var/spool/cron/titine, /var/spool/cron/root etc. Initialement, le répertoire /var/spool/cron/ est vide. C'est aux utilisateurs de créer leur crontab, selon des procédures que nous expliciterons plus bas.
Comment est indiqué le moment prévu pour l'exécution de la tâche
Regardons le fichier /etc/crontab afin de nous familiariser avec la syntaxe crond. Dans la configuration par défaut, la fin du fichier ressemble à ceci (nous simplifions légèrement) :
01 * * * * root run-parts --report /etc/cron.hourly
02 4 * * * root run-parts --report /etc/cron.daily
22 4 * * 0 root run-parts --report /etc/cron.weekly
42 4 1 * * root run-parts --report /etc/cron.monthly
Entre le dernier champ donnant une indication de temps et le champ qui contient la commande à exécuter, dans /etc/crontab et dans les éventuelles crontab contenues dans /etc/cron.d, figure l'indication du nom de l'utilisateur (root dans notre exemple) sous l'identité duquel la commande sera exécutée. Ce champ est en revanche absent des crontab d'utilisateurs de /var/spool/cron/nom-de-l'utilisateur.
Chaque ligne commence par une série de 5 champs qui indiquent, dans notre exemple, quand la commande run-parts sera exécutée :
- le premier champ indique la minute (un nombre de 0 à 59)
- le second champ indique l'heure (un nombre de 0 à 23)
- le troisième indique le jour du mois (un nombre de 1 à 31)
- le quatrième indique le mois (soit par un nombre de 1 à 12, soit par un nom court : jan/feb/mar/apr/may/jun/jul/aug/sep/oct/nov/dec)
- le cinquième indique le jour de la semaine (soit par un chiffre de 0 à 7 - le dimanche peut être représenté par le chiffre 0 ou par le chiffre 7, le chiffre 1 représente le lundi etc. - soit par un nom court, à savoir, de dimanche à samedi : sun/mon/tue/wed/thr/fri/sat).
Un astérisque (*) indique une « non condition » qui doit être comprise (selon sa position) comme : « peu importe la minute, l'heure, le mois ou le jour de la semaine ».
Regardons de près la dernière ligne du fichier. On peut y lire : la commande sera exécutée à la 42ème minute de la 4ème heure du 1er jour de chaque mois. Peu importe donc le mois (* dans la 4ème colonne) ou le jour de la semaine (* dans la 5ème colonne). La commande run-parts traitera donc les commandes du dossier /etc/cron.monthly tous les premiers jours du mois, à 4 heures 42. Les commandes du dossier /etc/cron.hourly seront, elles, traitées chaque jour à chaque heure et une minute (à minuit et une minute, à une heure et une minute etc.).
Voyons quelques autres exemples :
* * * * * commande1
la commande commande1 sera exécutée toutes les minutes, sans se soucier de l'heure, du jour ou du mois.
* * * * mon commande2
la commande commande2 sera exécutée toutes les minutes, mais uniquement le lundi (mon = Monday = lundi).
Que fait cette commande-là, d'après vous ?
44 14 * 11 wed commande3
Alors ?
La commande commande3 sera exécutée tous les mercredis (wed = Wednesday = mercredi) de novembre (11) à 14h 44.
Il est important de bien comprendre comment le troisième champ (jour du mois) et le cinquième champ (jour de la semaine) sont interprétés, lorsqu'ils sont tous les deux spécifiés.
Supposons, par exemple, que vous changiez la dernière ligne de /etc/crontab pour aboutir à ceci :
42 4 1 * sun commande
On pourrait croire que cela limiterait l'exécution de la commande commande au premier jour de chaque mois à 4h 42 si ce jour est un dimanche (sun). En fait, si les champs 3 et 5 sont différents de *, la commande sera exécutée chaque fois que la condition exprimée par l'un des deux champs est satisfaite. Dans ce cas, par conséquent, elle sera exécutée tous les 1er de chaque mois et aussi tous les dimanches.
Dans une crontab on peut aussi spécifier des plages de valeurs (x-y), des listes (x,y,z) et des valeurs par pas (éventuellement combinées avec des plages, x-y/z). Mais voyons cela sur un exemple :
05-15,30-40/3 8,12,16 * */2 7 commande
Pas facile, n'est-ce pas ? ;-) Voici une méthode de lecture : lorsque vous avez à déchiffrer des règles crond plutôt complexes, lisez les champs de la droite vers la gauche. Ce qui précède signifie donc que :
la commande commande est exécutée :
- les dimanches (7)
- un mois sur deux (*/2), donc en janvier, mars, mai...
- aux 8ème, 12ème et 16ème heures de la journée (8,12,16)
- toutes les minutes de la 5ème à la 15ème minute (05-15)
- puis toutes les 3 minutes entre 30 et 40 (30-40/3).
En janvier 2012, cette commande sera donc exécutée les dimanches 1er, 8, 15, 22 et 29, toutes les minutes de 8h 05 à 8h 15 incluses, puis toutes les 3 minutes de 8h 30 à 8h 40, c'est-à-dire à 8h 30, 8h 33, 8h 36 et 8h 39. Idem à la 12ème heure et à la 16ème heure.
Vous voyez à quel point vous êtes maître du temps lorsque vous écrivez dans une crontab !
Écrire et gérer votre propre table de planification crontab
Les commandes de cette section ne concernent que les crontab d'utilisateurs. Vous ne pourrez pas éditer la crontab du système /etc/crontab avec ces commandes (dans ce cas utilisez un éditeur de texte comme vous en avez l'habitude).
Si vous exécutez les commandes de cette section sous root, elles concerneront donc uniquement la crontab de l'administrateur root (fichier /var/spool/cron/root) et non pas la crontab du système ( /etc/crontab).
Pour modifier ou créer votre fichier crontab (le fichier relatif à votre compte utilisateur Linux, fichier qui, je vous le rappelle, sera entreposé dans /var/spool/cron), et qui s'appellera /var/spool/cron/toto si votre nom d'utilisateur est toto, tapez :
qui ouvre un nouveau fichier de configuration (ou le fichier existant, s'il y en a un) dans un éditeur.
Il est tout à fait déconseillé d'éditer les crontab d'utilisateur autrement que via la commande crontab -e
Assez bizarrement, il pourrait arriver que, par défaut, vous ne soyez pas autorisé à éditer votre crontab sous votre identité de simple utilisateur non root. Si c'est le cas, créez, sous root, un fichier texte /etc/cron.allow, où seront énumérés les utilisateurs du système autorisés à éditer leur crontab. Un /etc/cron.allow comme, par exemple :
toto
glin
autoriserait les utilisateurs toto et glin - et eux seuls - à éditer leur crontab.
Une solution alternative serait de créer un fichier /etc/cron.deny qui énumèrerait de la même façon les seuls utilisateurs qui ne seraient pas autorisés à éditer leur crontab. Le plus simple est alors de créer sous root un fichier de ce genre… vide, par la commande :
tous les utilisateurs seront alors autorisés à éditer leur crontab.
Par défaut, crontab utilise l'éditeur Vi.
Si l'éditeur par défaut Vi ne vous est pas familier, notez cependant que les trois commandes suivantes de Vi vous suffiront largement pour éditer une crontab :
- i vous met en mode « insertion »
- <ESC>:x (touche Echap puis les 2 touches :x) + <ENTREE> sauve le fichier en cours d'édition et quitte l'éditeur
- <ESC>:q! (touche Echap puis les 3 touches :q! ) + <ENTREE> quitte l'éditeur sans prendre en compte les modifications éventuelles.
crontab vous permet toutefois d'utiliser un autre éditeur que Vi, par exemple Kate ou Gedit ou tout autre qui vous conviendrait. Pour cela, exécutez une commande comme celle-ci avant d'appeler crontab, ou pour un emploi permanent, placez-la dans votre ~/.bashrc :
Notez que vous devez donner le chemin complet de l'éditeur : pour savoir quel est exactement ce chemin pour un éditeur donné, taper whereis + nom de l'éditeur, par exemple :
vous donnera : /usr/bin/kate.
Sachez qu'il existe aussi diverses interfaces graphiques d'édition des crontab, telles que, sous KDE, Configurer votre bureau -> Avancé -> Planificateur de tâches. Attention, si vous créez une tâche avec de tels outils, votre crontab actuelle (/var/spool/cron/nom_d_utilisateur) sera écrasée : il peut être prudent de commencer par la sauvegarder.
Lorsque vous éditerez votre crontab n'hésitez pas à y mettre des « commentaires », sous forme de lignes commençant pas un dièse (#), qui vous aideront à vous souvenir de la finalité des commandes que vous avez placées dans la table (voir plus bas pour un exemple). Le contenu de ces commentaires ne sera jamais exécuté par crond.
Pas de commentaire en fin de ligne dans une crontab ! Contrairement à ce qui est le cas dans divers langages de programmation et notamment dans le shell Bash, dans une crontab un signe de commentaire (dièse) ne peut être placé qu'en début de ligne, jamais après la commande.
Les commandes qui occupent plusieurs lignes ne sont pas autorisées, à moins de terminer la ligne par le caractère '\' (une convention qui est valable aussi pour les scripts du shell) : ce qui suit le '\' sera alors considéré comme appartenant à la même « grande ligne ». Vous pouvez aussi mettre une commande longue dans un script et appeler ce script à partir de la crontab.
Les autres options de crontab sont -l et -r :
se borne à afficher le contenu de votre crontab et
détruit votre crontab.
Effacer une crontab ou la commenter ? Plutôt que d'effacer votre crontab, il peut être astucieux de placer un commentaire en tête de toutes les lignes de commande qu'elle contient. Il vous sera ensuite très facile de réactiver tout ou partie des commandes (éventuellement après les avoir modifiées), en supprimant simplement la totalité ou une partie des dièses.
Si vous avec recueilli auprès d'un collègue une crontab complexe dont vous voudriez faire votre propre crontab (en lui apportant ensuite éventuellement quelques modifications), c'est très facile, supposons que cette crontab soit un fichier /home/crontab_juliette, pour en faire votre crontab, il suffira de lancer la commande suivante sous votre propre identité (après avoir par précaution sauvegardé votre crontab d'origine) :
Si vous voulez éditer la crontab d'un autre utilisateur du système, vous devez passer sous root (avec la commande su -) puis utiliser la commande crontab ainsi :
Recevoir par mail la sortie des commandes lancées par crond
Si la commande exécutée par le démon crond produit un affichage ou si un message d'erreur est engendré, un mail en transmet le contenu au propriétaire de la crontab responsable de l'exécution de la commande. Il faut avoir installé et activé un serveur de mail local comme Postfix pour que le mail arrive à son destinataire. Lorsque le destinataire est root le message doit être redirigé vers le compte de simple utilisateur de l'administrateur, de la façon indiquée à la page du Wiki qui traite du mail local. Il est possible de définir un destinaire du message autre que le destinataire par défaut en assignant une valeur à la variable MAILTO, comme dans cet exemple :
MAILTO=""
0 * * * * job1
MAILTO=alberto
0 * * * mon job2
Pour le job1, aucun mail ne sera envoyé (même si le programme échoue). Le mail d'information sera envoyé à l'utilisateur alberto pour le deuxième job.
Les variables de crond
Nous l'avons vu à l'instant, il est possible d'assigner, au sein d'une crontab, une valeur à certaines variables, qui seront ensuite utilisées comme « environnement » par crond pour exécuter les jobs.
Nous avons mentionné la variable MAILTO qui sert à déterminer le destinataire par défaut du courrier (le gestionnaire de courrier peut cependant effectuer des redirections).
Il est aussi possible d'utiliser une variable SHELL pour définir le shell (sh, Bash etc.) utilisé.
On peut également définir une variable PATH, contenant les « chemins » où crond cherchera les commandes à exécuter. On peut même définir une variable HOME qui déterminera relativement à quel « répertoire de travail » seront exécutées les commandes des jobs énumérés dans la crontab.
Chemins absolus ou relatifs dans une crontab : Attention, lorsqu'une commande crontab est exécutée sous l'identité d'un utilisateur, elle ne prend pas en compte tout l'environnement de cet utilisateur et notamment les valeurs de la variable PATH. Par conséquent, vous devez :
- ou bien écrire les commandes (et les éventuels fichiers passés en argument) avec leur chemin absolu (par exemple : si vous êtes l'utilisateur toto, pour lancer le script sauvliens.sh vous écrirez /home/toto/bin/sauvliens.sh, et non simplement sauvliens.sh, même si /home/toto/bin est dans votre PATH d'utilisateur)
- ou bien vous définissez une valeur pour la variable PATH propre à la crontab et vous pouvez utiliser alors des chemins relatifs par rapport aux chemins figurant dans cette variable propre à la crontab (par exemple : si vous placez dans le PATH de la crontab le chemin /home/toto/bin, vous pourrez lancer le script évoqué plus haut en écrivant simplement sauvliens.sh).
Voici par exemple les premières lignes de /etc/crontab dans Mandriva 2010.2 et dans la RC1 de Mandriva 2011 :
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/
La variable DISPLAY peut être utilisée pour lancer une application qui crée des fenêtres (une application dite « graphique »), voir là-dessus la section suivante.
Il est enfin tout à fait possible de créer une variable de votre choix, à utiliser ensuite dans les commandes constitutives des jobs, un exemple un peu bête mais illustratif serait ceci :
MESSAGE='A la bouffe !'
0 13 * * * echo "$MESSAGE"
qui vous enverrait chaque jour à 13h un mail contenant le message A la bouffe ! …
Lancer une application graphique avec crond
Sur certaines installations de Mandriva, une bogue empêche le lancement d'applications graphiques via cron, fcron ou anacron. Un contournement possible est discuté dans ce fildu forum Mandriva.
Si vous rencontrez cette bogue (et dans ce cas seulement), vous pouvez la contourner en autorisant tous les utilisateurs locaux (autrement dit les utilisateurs de votre ordinateur et non ceux de votre réseau) à se connecter à votre serveur graphique, en ajoutant dans votre fichier de configuration ~/.bashrc, la ligne :
xhost + local:
Lorsque vous lancez une application graphique (autrement dit une application qui utilise des fenêtres) avec crond vous devez lui dire explicitement sur quel serveur graphiques vous vous trouvez.
D'ordinaire vous êtes sur un serveur graphique dont le nom est
:0 ou :0.0
La variable DISPLAY contient le nom de votre serveur graphique, la commande suivante vous permettra de le déterminer :
:0.0
Pour lancer des applications graphiques, deux façons de faire sont possibles.
Vous pouvez donner la valeur appropriée à la variable DISPLAY dans votre crontab ou bien vous pouvez lancer l'application graphique en lui indiquant le nom du serveur grâce à l'option --display.
Pour lancer, avec Zenity, un message chaque premier quart d'heure de chaque heure du premier jour du mois, vous pourriez donc utiliser une /etc/crontab de ce genre (1ère des deux techniques possibles, qui utilise la variable DISPLAY) :
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ DISPLAY=:0.0 15 * 1 * * toto zenity --warning --title "Alerte" --text "Ne pas oublier le chèque mensuel à Z." # run-parts 01 * * * * root nice -n 19 run-parts --report /etc/cron.hourly 02 4 * * * root nice -n 19 run-parts --report /etc/cron.daily 22 4 * * 0 root nice -n 19 run-parts --report /etc/cron.weekly 42 4 1 * * root nice -n 19 run-parts --report /etc/cron.monthly
Une autre possibilité serait la suivante (utilisation de l'option --display) :
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ 15 * 1 * * toto zenity --warning --title "Alerte" --text "Ne pas oublier le chèque mensuel à Z." --display :0.0 # run-parts 01 * * * * root nice -n 19 run-parts --report /etc/cron.hourly 02 4 * * * root nice -n 19 run-parts --report /etc/cron.daily 22 4 * * 0 root nice -n 19 run-parts --report /etc/cron.weekly 42 4 1 * * root nice -n 19 run-parts --report /etc/cron.monthly
Bien entendu, si vous voulez traiter le cas où votre ordinateur serait éteint pendant un jour (ou plusieurs) en début de mois, vous pourriez envisager la possibilité de créer une commande anacron ou une commande fcron. Voir la section sur anacron ou la section sur fcron.
Exemple : compression mensuelle du répertoire des mails envoyés
Le principe général de cet exemple : lancer le script proposé ci-dessous (après l'avoir un peu adapté à votre propre usage) à l'aide de crond.
Vous voulez que crond réalise la compression de votre dossier (ou fichier) sent_mail (supposé contenir les courriers électroniques que vous avez envoyés à partir d'un certain compte), que le fichier d'archive ainsi obtenu soit stocké quelque part et que le dossier d'origine soit ensuite vidé. Créez alors un script comme celui-là :
#! /bin/bash # tar czf $HOME/mail/sent_mail$(date +%b%Y).tar.gz /chemin_du/repertoire_ou_fichier_sent_mail # pour les fichiers mail au format mbox : if [ "$?" -eq "0" ]; then /bin/echo > /chemin_du/fichier_sent_mail else /bin/echo "Impossible de créer l'archive" exit 1 fi # pour les répertoires de mails au format mh : if [ "$?" -eq "0" ]; then /bin/rm -f /chemin_du/repertoire_sent_mail/* else /bin/echo "Impossible de créer l'archive" exit 1 fi
Avant de revenir à cron, quelques mots d'explication sur ce script seront sans doute bienvenus... (pour vous initier à l'art d'écrire un script shell, lisez donc cette autre page du Wiki : Ecrire un script shell).
Tout d'abord pour comprendre le fonctionnement et la syntaxe de la commande tar qui permet de créer des fichiers d'archive, vous pourrez consulter cette page du Wiki.
Notez ensuite que la variable d'environnement HOME contient le chemin de votre répertoire personnel (par exemple, /home/toto).
La variable spéciale $? contient le « code de retour » de la commande qui vient d'être exécutée (ici donc : tar). Si ce code est nul, c'est que tout s'est bien passé. Sinon (else), c'est que l'archive n'a pu être créée correctement et le script s'arrête immédiatement en renvoyant un code d'erreur (exit 1).
L'utilisation du if évite donc de supprimer le fichier ou le répertoire sent_mail si la commande tar n'a pas pu créer une archive (sinon, dans un tel cas, vous perdriez tous les messages que vous vouliez archiver !). Bien entendu, seule une des deux structures en if subsistera dans votre script réel, vous devrez choisir l'une ou l'autre selon que vos messages envoyés sont stockés dans un unique fichier (premier if) ou dans des fichiers multiples à l'intérieur d'un répertoire (second if). Le if teste donc la « valeur de retour » de la commande qui vient d'être exécutée (ici tar), valeur de retour qui est toujours placée par le shell dans la variable spéciale du shell : $? ; une valeur de zéro représente le succès de la commande tar, toute valeur différente représenterait un code d'erreur indiquant que l'archive n'a pu être créée correctement. Dans le premier if, le fichier contenant les messages sera vidé de son contenu en redirigeant vers lui la sortie nulle de la commande echo employée sans argument (pour le sens de l'indicateur de redirection >, voir Le shell sans peine : techniques avancées#Redirection vers un fichier ou en provenance d'un fichier). Pour la commande rm, utilisée dans le second if, voir Le shell sans peine#Pour nettoyer, l'option -f empêche toute demande de confirmation. Enfin exit 1 interrompt le script (ici, sans rien supprimer) en renvoyant le code d'erreur 1.
Vous voyez bien que ce n'est pas si compliqué que cela !!!
Pour rendre les choses plus concrètes, si vous utilisez le courielleur Thunderbird, vous choisirez la première version de if et un fichier de courrier envoyé aura un chemin du type suivant (si votre nom d'utilisateur est toto)
/home/toto/.thunderbird/<repertoire_de_profil>/Mail/<repertoire_de_compte_mail>/Sent
qui pourrait être par exemple :
/home/toto/.thunderbird/k3bs9mbp.default/Mail/pop.free.fr/Sent
Un exemple de script réel est alors :
#! /bin/bash # Script archive_mail.sh # # Création de l'archive du mois tar czf $HOME/mail/sent_mail$(date +%b%Y).tar.gz $HOME/.thunderbird/k3bc9mpb.default/Mail/pop.free-3.fr/Inbox # Si succès effacement du fichier d'origine, sinon message d'erreur et sortie if [ "$?" -eq "0" ] ; then echo > $HOME/.thunderbird/K3bc9mpb.default/Mail/pop.free-3.fr/Inbox else /bin/echo "Impossible de créer l'archive." exit 1 fi
Rendez le script exécutable avec chmod +x fichier (sur la commande chmod, voir Permissions#Modifier les propriétés d'accessibilité à l'aide de chmod). Testez en utilisant un fichier de sauvegarde (c'est toujours une bonne idée de tester ses scripts avant qu'ils ne causent des dommages).
Ensuite éditez votre crontab avec crontab -e et ajoutez-y ces lignes :
# pour les mois de 31 jours 59 23 31 1-7/2,8-12/2 * sh votre_script_avec_le_chemin_complet # pour les mois de 30 jours 59 23 30 4,6,9,11 * sh votre_script_avec_le_chemin_complet # enfin, pour février. 59 23 28 2 * sh votre_script_avec_le_chemin_complet
Si tout se passe bien, le démon crond appellera votre script la dernière minute de chaque mois. Le script compressera le fichier ou le dossier sent_mail, stockera le résultat sous $HOME/mail/sent_mail~MoisAnnée.tar.gz et videra le fichier ou le répertoire sent_mail.
Mais attention ! vous devez être sûr que votre PC sera allumé la dernière nuit de chaque mois ! Car un job de crontab ne sera PAS exécuté du tout si l'ordinateur est fermé au moment prévu pour son exécution, notez bien qu'à la différence d'un job de at, un job crond ne sera pas lancé au démarrage de l'ordinateur dans ce cas...
Si vous n'en êtes pas sûr, alors, il va falloir penser à utiliser anacron et donc à poursuivre votre lecture jusqu'à la section suivante...
Exécution régulière d'une tâche sur un ordinateur souvent éteint : anacron
Si vous regardez le contenu du fichier /etc/crontab, le fichier de configuration du démon crond, dont il a été question plus haut, vous pourrez observer que, par défaut, les tâches quotidiennes, hebdomadaires ou mensuelles prévues par le système sont exécutées entre 4 et 5 heures du matin. Si votre ordinateur n'est pas allumé à ce moment-là, les « jobs » de cron risqueraient donc de n'être tout simplement pas exécutés !!
Une solution possible serait de modifier les champs d'heure en leur donnant une valeur correspondant à un moment de la journée où il est probable que votre ordinateur soit allumé (j'ai, un temps, mis moi-même tout cela à 14h).
Une autre possibilité serait d'avoir recours au programme anacron.
La première chose à faire dans ce cas est de vous assurer que ce programme est installé sur votre système. Pour cela en console, tapez la commande suivante, vous devriez obtenir le résultat indiqué :
anacron: /usr/sbin/anacron
Si au contraire vous obtenez un résultat 'vide' comme :
anacron:
installez alors le paquetage pour anacron : cronie-anacron.
Notez bien qu'anacron n'est pas du tout destiné à remplacer cron, il s'y ajoute et coexiste avec lui...
Sous les anciennes versions de Mandriva, et encore maintenant dans d'autres distributions Linux, anacron était un démon qui s'éveillait au démarrage de l'ordinateur, exécutait les jobs en attente, et se rendormait aussitôt jusqu'au prochain redémarrage (ou jusqu'à une sollicitation manuelle de l'administrateur du système si celui-ci avait modifié l'inventaire des jobs). Il n'en est plus ainsi.
Sous Mandriva anacron n'est plus un service du système.
C'est une commande dont le lancement est entièrement contrôlé par crond.
Voir plus bas pour plus de détails. Et voir plus haut pour une description du fonctionnement de crond.
anacron (en anglais anachronistic command scheduler ou planificateur de commande « anachronique ») utilise des indications de temps relatives (« une fois par jour / par semaine / par mois ») au lieu de références temporelles absolues (« le 14 janvier 2008 à 15h 30 »). De la sorte, même si vous « manquez » - parce que l'ordinateur était éteint - un moment ou une date particulière où l'exécution d'un « job » était prévue, celui-ci sera tout de même exécuté peu de temps après le prochain démarrage du système.
Pour anacron, la plus petite unité de temps est le jour. anacron ne connaît pas l'heure, la minute, la seconde.
Typiquement anacron s'exécute une fois par période de 24h (sauf si l'administrateur a modifié l'inventaire des jobs et souhaite relancer anacron avec cet inventaire modifié).
Voici comment cela fonctionne :
- quand anacron est lancé, il recherche les « fichiers dateurs » (anglais timestamps) correspondant à ses différents jobs dans /var/spool/anacron, ces fichiers ne contiennent rien d'autre que la date de la dernière exécution du job (20110803 : pour le 3 août 2011, par exemple)
- si, d'après un des fichiers dateurs, un job est en attente, anacron le lance
- anacron met à jour le fichier dateur du job en question.
Le fonctionnement d'anacron est contrôlé par le fichier /etc/anacrontab. Voici une version simplifiée du /etc/anacrontab de la Mandriva 2010.2 :
Son contenu se répartit en quatre champs séparés par des espaces (un seul suffirait) :
1 5 cron.daily run-parts /etc/cron.daily 7 25 cron.weekly run-parts /etc/cron.weekly @monthly 45 cron.monthly run-parts /etc/cron.monthly
- Le premier champ représente la période en jours : 1 pour une exécution quotidienne, 7 pour une exécution tous les 7 jours (fréquence hebdomadaire), @monthly pour une exécution chaque mois, @yearly pour une exécution chaque année etc.
- Le deuxième champ représente la durée, en minutes, qui doit séparer le lancement d'anacron de l'exécution d'un job. Ainsi, 5 revient à dire « lancez le job prévu 5 minutes après l'activation d'anacron ». Ceci permet d'éviter que tous les jobs de la file ne soient lancés en même temps.
- Le troisième champ contient un identifiant du job. anacron utilise cet identifiant pour ses fichiers dateurs et ses messages. Dans notre exemple, les identifiants sont donc de la première à la dernière ligne : cron.daily, cron.weekly et cron.monthly
- Le quatrième champ contient la commande à exécuter. Dans notre exemple, il s'agit pour chaque job de la commande run-parts suivie de son argument (le chemin du répertoire qui contient les scripts que run-parts va lancer). Sur run-parts, voir #La commande run-parts.
Anacron n'est pas lancé si l'ordinateur que vous utilisez n'est pas sur secteur. Ainsi, il n'entraîne pas de consommation supplémentaire pour un portable sur batterie.
Dans la véritable anacrontab de Mandriva, la commande d'un job est toujours la commande nice, une commande qui prend comme argument une autre commande et la lance en lui attribuant un certain degré de priorité. Vous trouverez donc en réalité dans votre anacrontab des lignes comme celle-ci :
1 5 cron.daily nice -n 19 run-parts /etc/cron.daily
Ici nice exécute la commande run-parts /etc/cron.daily (sur run-parts, voir plus bas #La commande run-parts) en lui attribuant la priorité la plus faible disponible (priorité 19), afin que l'exécution des tâches de fond d'anacron ne perturbe pas votre travail quotidien sur l'ordinateur.
Reste maintenant à savoir comment est allumée la mèche, autrement dit comment et quand est lancé anacron.
Sous une Mandriva actuelle, c'est crond qui lance anacron.
A chaque heure pile + 1 minutes, crond lance l'ensemble des scripts contenus dans le répertoire /etc/cron.hourly, comme le montre cette ligne de /etc/crontab :
01 * * * * root nice -n 19 run-parts --report /etc/cron.hourly
or le premier de ces scripts est /etc/hourly/0anacron qui lance lui-même anacron.
Autrement dit, dès que vous allumez votre ordinateur dans la journée, il suffit d'attendre la première minute suivant la prochaine heure pile pour qu' anacron soit lancé et prenne soin de tous vos jobs en attente.
Les limites d'anacron
anacron ne peut remplacer cron, pour toute une série de raisons.
anacron ne possède aucun mécanisme permettant de lancer des jobs sous les identités de différents utilisateurs : anacron lance tous ses jobs sous root. cron en revanche permet de définir des jobs qui seront exécutés sous l'identité de n'importe quel utilisateur du système.
Contrairement à cron, anacron ne peut exécuter des jobs toutes les minutes ou toutes les heures : l'unité de temps d'anacron est essentiellement la journée...
Il faut bien comprendre qu'anacron dans son emploi prototypique se lance une fois par jour (sous Mandriva ce sera une heure au plus après le démarrage du système), exécute ses jobs et s'endort jusqu'au lendemain (sauf si l'administrateur a modifié la liste des jobs dans la journée et que lui-même (ou crond) relance anacron). Alors que crond peut être lancé beaucoup plus fréquemment (jusqu'à une fois par minute si nécessaire).
Si vous modifiez l'inventaire des jobs et voulez les faire exécuter immédiatement par anacron, vous pouvez toutefois lancer anacron « à la main » avec la commande :
les jobs en attente à ce moment seront alors lancés les uns à la suite des autres (l'option -s garantit que les jobs ne seront pas exécutés simultanément ; pour lancer tous les jobs immédiatement employer à la place l'option -n).
Comme le programme at et le programme batch, ainsi que le programme crond, anacron n'affiche pas par défaut sa sortie sur une console (à moins qu' anacron ne soit lancé manuellement avec l'option -d qui force l'affichage en console).
En revanche, elle envoie par courrier à root le contenu de la sortie des commandes qu'elle exécute, mais pour pouvoir lire ce courrier vous devez bien sûr avoir installé le mail local.
Les variables d'anacron
Comme on peut le faire dans les crontab, il est possible aussi d'assigner une valeur à des variables dans le fichier anacrontab.
On peut ainsi définir un PATH pour les jobs anacron, une variable SHELL contenant l'interpréteur de commande à utiliser, et un destinataire par défaut des message de courrier local dans la variable MAILTO.
L'anacrontab de Mandriva contient par exemple, par défaut, ces lignes :
SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
(notez que sous Mandriva /bin/sh est un lien vers /bin/bash).
L'anacrontab de Mandriva contient aussi deux variables particulièrement intéressantes :
# the maximal random delay added to the base delay of the jobs RANDOM_DELAY=45 # the jobs will be started during the following hours only START_HOURS_RANGE=6-22
Nous avons vu plus haut que le deuxième champ d'un job dans une anacrontab contient un délai en minutes qui est censé définir un intervalle de temps entre le démarrage d'anacron et le démarrage du job concerné. En réalité, cet intervalle vaut à chaque lancement un nombre de minutes défini par la somme du contenu de ce deuxième champ et d'une valeur aléatoire déterminée par la variable RANDOM_DELAY, ici on ajoute à chaque exécution un nombre de minutes variant au hasard entre 0 et 45 à la valeur du deuxième champ défini dans l'anacrontab. Ce champ n'est donc qu'un minimum. Un job comme :
1 5 cron.daily nice -n 19 run-parts /etc/cron.daily
sera donc exécuté, 5, ou 6, ou 7 ou 8... ou 49 ou 50 minutes, après le lancement d'anacrontab, la valeur variant d'une exécution à l'autre de façon imprévisible.
La variable START_HOURS_RANGE définit la période pendant laquelle les jobs anacron pourront être exécutés (par défaut, donc, sous Mandriva, ce sera uniquement entre 6h et 22h). En dehors de cette période rien n'empêche en revanche des jobs cron d'être exécutés...
On peut même définir une variable de son choix à utiliser dans un job. Une anacrontab qui contiendrait ceci :
MESSAGE="C'est pour aujourd'hui !!" 30 0 * * * echo "$MESSAGE"
enverrait par mail tous les 30 jours le message « C'est pour aujourd'hui !! ».
Lancer une application graphique avec anacron
Sur certaines installations de Mandriva, une bogue empêche le lancement d'applications graphiques via cron, fcron ou anacron. Un contournement possible est discuté dans ce fildu forum Mandriva.
Si vous rencontrez cette bogue (et dans ce cas seulement), vous pouvez la contourner en autorisant tous les utilisateurs locaux (autrement dit les utilisateurs de votre ordinateur et non ceux de votre réseau) à se connecter à votre serveur graphique, en ajoutant dans votre fichier de configuration ~/.bashrc, la ligne :
xhost + local:
Les techniques à utiliser pour lancer une application graphique sous anacron sont identiques à celles que nous avons vu plus haut sous cron. Voir ici.
Voici par exemple une /etc/anacrontab qui afficherait chaque mois un message avec Zenity.
# /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=45 # the jobs will be started during the following hours only START_HOURS_RANGE=6-22 @monthly 0 rappel zenity --warning --title "Alerte" --text ""Ne pas oublier le chèque mensuel à Z." --display :0.0 #period in days delay in minutes job-identifier command 1 5 cron.daily nice -n 19 run-parts --verbose /etc/cron.daily 7 25 cron.weekly nice -n 19 run-parts --verbose /etc/cron.weekly @monthly 45 cron.monthly nice -n 19 run-parts --verbose /etc/cron.monthly
La commande run-parts
La commande run-parts a pour effet de lancer tous les fichiers exécutables contenus dans le répertoire qui lui est passé en argument.
Ces exécutables sont lancés les uns après les autres (pas d'exécution simultanée), dans l'ordre alphabétique de leur nom.
Elle est utilisée par le système pour l'exécution des tâches périodiques régulières par l'entremise du démon crond ou éventuellement d'anacron.
Ainsi, sous Mandriva, le fichier de configuration de crond : /etc/crontab, se présente pour l'essentiel ainsi :
01 * * * * root run-parts --report /etc/cron.hourly 02 4 * * * root run-parts --report /etc/cron.daily 22 4 * * 0 root run-parts --report /etc/cron.weekly 42 4 1 * * root run-parts --report /etc/cron.monthly
/etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly et /etc/cron.monthly sont des répertoires qui contiennent des programmes à exécuter.
Chacune des quatre lignes de cette crontab signifient donc que, lorsque l'ordinateur est allumé :
- (1ère ligne) toutes les heures, à la première minute, les programmes du répertoire /etc/cron.hourly sont lancés par run-parts (par conséquent à 00h 01, 1h 01, 2h 01 etc.)
- (2ème ligne) tous les jours, à 4h 02, les programmes du répertoire /etc/cron.daily sont lancés par run-parts
- (3ème ligne) tous les dimanches, à 4h 22, les programmes du répertoire /etc/cron.weekly sont lancés par run-parts
- (4ème ligne) tous les 1er du mois, à 4h 42, les programmes du répertoire /etc/cron.monthly sont lancés par run-parts
(pour plus de détails sur crond et sur les crontab, voir la section sur crond).
L'option --report de run-parts affiche dans la sortie de la commande le nom des fichiers exécutés lorsqu'ils ont eux-même une sortie. Cette option affecte le contenu du message envoyé à l'administrateur par crond ou anacron par l'entremise du mail local et le rend plus facile à interpréter. Pour obtenir plus d'informations, on peut remplacer --report par --verbose : on obtient ainsi - toujours dans le message envoyé par mail - le nom de tous les jobs exécutés, même s'ils ne génèrent aucune sortie. Pour installer le mail local sur votre machine voir ici.
Il est possible de régler la priorité des exécutables lancés par run-parts - par rapport aux autres processus du système - en utilisant la commande nice. Par exemple, pour leur donner une priorité faible par rapport aux processus courants, on peut avoir une /etc/crontab comme ceci (c'est ce qu'on trouve dans la véritable crontab par défaut de Mandriva) :
01 * * * * root nice -n 19 run-parts --report /etc/cron.hourly 02 4 * * * root nice -n 19 run-parts --report /etc/cron.daily 22 4 * * 0 root nice -n 19 run-parts --report /etc/cron.weekly 42 4 1 * * root nice -n 19 run-parts --report /etc/cron.monthly
(la commande nice prend ici deux arguments : l'un est lui-même une commande, avec ses propres arguments (par exemple : run-parts --report /etc/cron.hourly) et l'autre : -n 19, définit une priorité pour l'exécution de la commande qui est argument de nice (ici run-parts), cette priorité (19) est la plus faible possible, ainsi l'exécution des jobs ne perturbera pas votre travail quotidien auxquels le processeur accordera la préférence, [notez que la priorité la plus forte attribuable par nice serait négative : -n -19]).
Sur une machine qui n'est pas allumée en permanence, anacron permet d'exécuter les tâches en souffrance qui n'ont pas pu être lancées par crond pendant la période où l'ordinateur était éteint. Ainsi, sous une Mandriva, le lancement de run-parts est aussi une tâche anacron intégrée au fichier /etc/anacrontab. Voir là dessus la section sur anacron.
Que font au juste crond et anacron sur ma Mandriva ?
Pour voir de vos yeux quelles tâches sont exécutées par crond et anacron et à quel moment, vous pouvez consulter le journal du système /var/log/messages, sous root tapez en console :
(vous voulez comprendre ? C'est simple, la commande tail lit la fin du fichier passé en argument, la quantité de lignes à lire étant définie par l'option -n 5000000; dans ces lignes la commande grep retient exclusivement celles qui contiennent anacron ou crond sans tenir compte de la différence entre majuscules et minuscules grâce à l'option -i, dans anacron|crond le | est un ou logique et l'option -E de grep permet d'interpréter ce | comme un ou)
Si vous ne voyez apparaître qu'un petit nombre de messages, c'est sans doute que l'archivage automatique du fichier par le programme logrotate vient d'avoir lieu, essayez alors de lire la première archive ainsi :
Vous devriez voir ce qui s'est passé pendant une petite dizaine de jours. L'exécution des tâches crond (celles du système et éventuellement celles de tous les utilisateurs) et l'exécution des tâches anacron apparaîtront.
Si vous n'avez pas modifié les paramétrages d'origine de vos /etc/crontab et /etc/anacrontab, vous devriez observer en gros ceci :
===============================Ce qui se passe sur ma Mandriva======================================
Tant que votre ordinateur est allumé, de nuit comme de jour, à chaque heure pile + une minute crond exécute la commande run-parts --report /etc/cron.hourly qui lance elle-même tous les exécutables contenus dans le répertoire /etc/cron.hourly/.
Les tâches quotidiennes (les fichiers exécutables contenus dans /etc/cron.daily), les tâches hebdomadaires (fichiers exécutables contenus dans /etc/cron.weekly), les tâches mensuelles (fichiers exécutables contenus dans /etc/cron.monthly) sont lancées ainsi :
- si votre ordinateur est allumé pendant la nuit :
- les tâches quotidiennes sont lancées par crond chaque nuit à 4h 1 minute
- les tâches hebdomadaires sont lancées par crond la nuit de chaque dimanche à 4h 22
- les tâches mensuelles sont lancées par crond la nuit du premier de chaque mois à 4h 42
- si votre ordinateur n'est allumé que dans la journée, à la première heure pile + 1 minute après le démarrage de l'ordinateur, anacron est réveillé par crond et lance successivement les différentes tâches quotidiennes, hebdomadaires et mensuelles en attente (avec un décalage temporel entre elles sur lequel vous trouverez des détails ici).
============================================================================================
Bien entendu, vous avez toute latitude de modifier tout cela, si vous le jugez bon, et notamment d'ajouter des tâches horaires, quotidiennes, hebdomadaires ou mensuelles, à votre convenance : il vous suffira d'ajouter des scripts, des fichiers exécutables ou des liens vers de tels fichiers dans les répertoires ad hoc mentionnés ci-dessus. Pour des modifications plus élaborées, lisez les sections précédentes sur cron et sur anacron pour savoir comment faire (n'oubliez pas de sauvegarder d'abord vos tables d'origine, par précaution).
Si vous avez installé le mail local sur votre machine, vous recevrez des messages de cron et anacron par mail. Si en outre vous avez remplacé partout dans votre /etc/crontab --report par --verbose et ajouté --verbose immédiatement après run-parts dans chaque ligne de job de votre /etc/anacrontab, vous verrez apparaître, dans ces messages, le nom de tous les exécutables lancés par run-parts.
Utiliser fcron à la place de cron+anacron
Mandriva et de nombreuses autres distributions lancent des tâches systèmes régulièrement en utilisant une combinaison de cron et anacron. Il peut donc être utile de connaître ces deux programmes, afin de personnaliser votre système.
Toutefois, il existe maintenant un programme fcron qui assume à lui seul les fonctionnalités de cron et anacron et quelques autres encore. Pour lancer des tâches régulières de votre choix, il peut être tout à fait intéressant d'utiliser ce logiciel.
Pour disposer de fcron il suffit d'installer le paquetage fcron à partir des dépôts Mandriva.
De la documentation sur ce programme :
- man fcron et man fcrontab sont disponibles en français après installation de fcron.
Sur certaines installations de Mandriva, une bogue empêche le lancement d'applications graphiques via cron, fcron ou anacron. Un contournement possible est discuté dans ce fildu forum Mandriva.
Si vous rencontrez cette bogue (et dans ce cas seulement), vous pouvez la contourner en autorisant tous les utilisateurs locaux (autrement dit les utilisateurs de votre ordinateur et non ceux de votre réseau) à se connecter à votre serveur graphique, en ajoutant dans votre fichier de configuration ~/.bashrc, la ligne :
xhost + local:La planification interactive et l'affichage de message : KAlarm
at, cron et anacron ne permettent pas de lancer des programmes qui demandent des informations à l'utilisateur, comme peuvent le faire les applications X. Ceci est dû au fait qu'elles ne possèdent pas de shell d'où lancer un programme. sleep peut permettre de faire cela, mais seulement dans le cours d'une seule et même session.
Le programme rclock et l'utilitaire KAlarm de KDE peuvent lancer des programmes interactifs à un moment prédéterminé.
Le programme rclock
Le programme rclock appartient au paquetage rxvt (installez-le par un simple urpmi rxvt sous root). On peut lui demander d'exécuter une commande incluant l'affichage de messages et/ou le lancement d'une application, y compris une application graphique, en éditant un fichier ~/.rclock.
On peut par exemple ajouter dans ~/.rclock la ligne suivante :
12:00 A la bouffe !!
par la commande :
Utilisez bien les guillemets simples, pour que le shell ne comprenne pas les points d'exclamation comme une commande concernant l'historique du shell.
Ce qui assurera l'affichage, chaque jour à midi, du subtil message indiqué (cet affichage suppose bien sûr que rclock soit lancé, par exemple par une commande rclock qui affichera l'icône du programme en permanence sur votre bureau).
Il est aussi possible de lancer ainsi une application...
Par exemple, vous lancerez automatiquement Thunderbird chaque jour à 12 h, en plaçant la ligne suivante dans votre ~/.rclock :
12:00 ; /usr/local/bin/thunderbird
à l'aide de la commande :
(je suppose que /usr/local/bin/thunderbird est un lien vers l'exécutable de Thunderbird, pour savoir ce qu'il en est chez vous, utilisez la commande whereis thunderbird).
Vous pouvez aussi afficher un message qui apparaîtra dans une fenêtre comportant un bouton Start que vous devrez presser pour lancer l'application (cliquer sur le bouton Defer amènera rclock à vous reposer la question plus tard et le bouton Done abandonnera le lancement), pour cela votre ~/.rclock devra comporter une ligne comme celle-ci :
12:00 Lancement de Thunderbird ? ; /usr/local/bin/thunderbird
Pour plus d'informations sur la syntaxe à utiliser dans le fichier ~/.rclock, lisez man rclock, qui se termine par un exemple détaillé.
Sous KDE, vous pouvez lancer systématiquement rclock au démarrage de la session en créant un lien symbolique vers l'exécutable de rclock (dont vous trouverez le chemin exact par un whereis rclock) dans le répertoire Autostart de KDE :
Sous GNOME, vous obtiendrez le même résultat en passant par Système > Préférences > Avancé -> Session > Programmes au démarrage.
L'utilitaire KAlarm de KDE
Cet utilitaire, très facile à configurer en remplissant des champs appropriés, faciles à repérer, dans une fenêtre de configuration bien conçue, permet, lui aussi, d'afficher des messages ou de lancer des applications graphiques à des moments déterminés.
Vous y accèderez via Menu > Outils > K Alarm.
KAlarm est doté d'une aide en français, il ne sera donc pas nécessaire que nous nous étendions davantage ici sur cet excellent outil.
