Cron

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Cron and the translation is 72% complete.
Outdated translations are marked like this.
Resources

Cet article explique comment configurer et utiliser les daemons cron dans Gentoo Linux.

Les fondamentaux de cron

Que fait cron ?

Cron est un daemon qui exécute des tâches programmées en se basant sur une table de commandes appelée crontab. Il exécute ces tâches en s'éveillant toutes les minutes et en regardant s'il y a des tâches à lancer dans une crontab quelconque de l'utilisateur.

Remarque
Noter que crontab est à la fois le nom d'une liste de 'tâches cron' et le nom de la commande d'édition de cette liste.
Remarque
When using the systemd init system, (persistent) timers are available as a replacement of (ana)cron.

Le cron de facto

Il y a plusieurs mises en œuvre de cron dans Portage parmi lesquelles choisir. Elles ont toutes la même interface, nommément l'utilisation de la commande crontab ou d'une commande similaire. Il existe également un utilitaire appelé Anacron qui est prévu pour fonctionner avec cron sur des systèmes qui ne fonctionnent pas en permanence.

Tous les paquets cron disponibles dépendent de sys-process/cronbase. Ce paquet n'est cependant pas techniquement nécessaire à aucun des paquets cron, mais il procure une fonctionnalité similaire à cron que la plupart des utilisateurs apprécient.

Avant de démarrer avec cron, une mise en œuvre de cron doit être choisie.

Quel cron choisir ?

Remarque
Utilisez virtual/cron pour installer l'implémentation cron par défaut de Gentoo.

cronie

Cronie (sys-process/cronie) est un fork de vixie-cron développé par Fedora. Comme il s'agit d'un fork il possède les mêmes fonctionnalités que l'original vixie-cron. De plus, cronie est fourni avec une implémentation d'anacron qui peut être activée via l'option anacron de la variable USE.

sys-process/cronie is a fork of the venerable vixie-cron, hosted at [1]. Because of it being a fork, it has the same feature set the original vixie-cron provides. Additionally, cronie comes with an anacron implementation which is enabled by default, through the anacron USE flag. Be aware of the configuration differences as noted in bug #551352 when migrating from another cron system. Expected jobs may not run at all.

dcron (le Cron de Dillon)

Dcron cherche à rester une mise en œuvre de cron, simple, élégante et sûre. Il n'autorise pas la spécification de variables d'environnement dans les crontabs et toutes les 'tâches cron' sont lancées depuis /bin/sh. Comme vixie-cron, chaque utilisateur dispose de sa propre crontab. A partir de la version 4, il contiens des fonctionnalités similaires à anacron.

Fonctionnalités de sys-process/dcron :

  • Rapide, simple et débarrassé de fonctionnalités inutiles;
  • L'accès à la crontab est limité au groupe cron, autrement dit il ne se fie pas à des facultés externes.

fcron

Fcron cherche à remplacer vixie-cron et anacron. Il est prévu pour fonctionner sur des systèmes qui ne sont pas toujours en marche et arrive avec des fonctionnalités supplémentaires. Il prévoit des contraintes de lancement des tâches, la sérialisation des contrôles, la possibilité d'ajouter des valeurs agréables aux tâches et la possibilité de programmer les tâches à lancer au démarrage du système. Voir la page d'accueil de fcron pour plus d'informations.

Fonctionnalités de sys-process/fcron :

  • Conçu pour fonctionner sur des systèmes qui ne marchent pas en permanence , c'est à dire qu'il peut relancer une tâche au redémarrage de la machine si elle a été manquée;
  • Définition de variables d'environnement et de beaucoup d'autres fonctionnalités dans les crontabs;
  • Syntaxe des crontab améliorée avec la prise en charge de plusieurs fonctionnalités nouvelles;
  • Chaque utilisateur dispose de sa propre crontab et l'accès est contrôlé par cron.allow et cron.deny

bcron

bcron est un nouveau système cron conçu pour des opérations sécurisées. Pour ce faire, le système est divisé en plusieurs programmes séparés, chacun responsable d'une tâche séparée, avec une communication strictement contrôlée entre eux. L'interface utilisateur est un remplacement dérivé de systèmes similaires (tel que vixie-cron), mais les aspects internes différent profondément. Pour de plus amples informations, se reporter à la page de bcron à http://untroubled.org/bcron.

Fonctionnalités de sys-process/bcron :

  • Remplaçant de vixie-cron;
  • Conception multi-processus;
  • Prise en charge native de l'heure d'été.

anacron

Anacron n'est pas un daemon cron, c'est un programme qui fonctionne en conjonction avec l'un d'eux. Il exécute des commandes à des intervalles spécifiées en jours et ne suppose pas que le système reste en marche continuellement ; il lance les tâches qui ont été manquées lorsque le système était arrêté. Ordinairement, Anacron compte sur un daemon cron pour être lancé tous les jours.

Utiliser cron

Installation

Choisir la bonne mise en œuvre de cron voulue, et l'installer :

root #emerge --ask dcron

S'assurer que le daemon cron choisi a été rajouté aux processus init du système; sans cette étape le daemon cron ne va pas effectuer son travail.

root #/etc/init.d/dcron start
root #rc-update add dcron default

En option, si Fcron ou dcron n'ont pas été installés, installer Anacraon comme aide au daemon cron peut être sage.

root #emerge --ask anacron

Encore, ne pas oublier d'ajouter anacron au processus init du système.

root #/etc/init.d/anacron start
root #rc-update add anacron default

Pour anacron, il n'y a généralement pas de processus d'initialisation. A la place, anacron doit être lancé via une autre système cron.

Une méthode consiste à lancer anacron à travers une définition cron. Par défaut, il installe un script, exécuté toutes les heures, qui est utilisé par la plupart des implémentations cron par défaut. Si ce n'est pas le cas, alors il peut également être lancé à travers des définitions manuelles :

FILE /etc/crontabLancer anacron via une définition manuelle
# Démarre anacron toutes les 10 minutes
*/10 * * *  root  /usr/sbin/anacron
 
# Il est également possible d'exécuter le script 0anacron fourni par anacron toutes les heures
# 59 * * * *  root  /etc/cron.hourly/0anacron

La crontab système

Les messages d'après installation de certains de ces paquets cron indiquent à l'utilisateur de lancer crontab /etc/crontab. Le fichier /etc/crontab est le crontab système. Une installation de cron peut l'utiliser en conjonction avec sys-process/cronbase pour lancer les scripts dans /etc/cron.{daily,hourly,weekly,monthly} . Noter que seul vixie-cron et cronie' programment les tâches dans /etc/crontab automatiquement. Les utilisateurs de dcron et de fcron devront lancer crontab /etc/crontab à chaque fois qu'ils apportent des modifications dans /etc/crontab .

Noter que les tâches programmées dans la crontab système peuvent ne pas apparaître dans la liste des tâches cron affichée par la commande crontab -l.

Bien-sûr, les utilisateurs peuvent choisir de ne pas utiliser une crontab système. Si dcron ou fcron ont été choisis , ne pas lancer crontab /etc/crontab. Si vixie-cron, cronie ou bcron ont été choisis, commenter toutes les lignes dans /etc/crontab.

Un moyen rapide et facile de commenter toutes les lignes dans un fichier est d'utiliser la commande sed. Exécuter la commande suivante pour commenter toutes les lignes dans etc/crontab

root #sed -i -e "s/^/#/" /etc/crontab

Donner un accès à cron à des utilisateurs de confiance

Pour que des utilisateurs autres que root aient accès au daemon cron, lire cette section, sinon, passer à la section suivante, Programmer des tâches cron .

Remarque
Donner l'accès à la crontab à un utilisateur ne lui permet pas de lancer des tâches cron en tant que root. Pour qu'un utilisateur soit capable d'éditer la crontab de root, regarder dans l'utilisation de sudo (app-admin/sudo). Se reporter au Guide Gentoo pour les utilisateurs de sudo pour plus de détails.

Peu importe le paquet cron utilisé, pour autoriser un utilisateur à utiliser crontab, il doit d'abord faire partie du groupe cron. Par exemple, pour ajouter l'utilisateur wepy au groupe cron, exécuter :

root #gpasswd -a wepy cron
Remarque
Lorsque un utilisateur est ajouté au groupe cron, s'assurer que l'utilisateur se déconnecte et se reconnecte pour que l'ajout au groupe soit effectif.

dcron

Si Dcron est utilisé, l'étape précédente est suffisante pour donner accès à crontab à un utilisateur. Les utilisateurs de Dcron peuvent passer à la section suivante Programmer des tâches cron , tous les autres doivent continuer à lire.

fcron

Si fcron est utilisé, éditer /etc/fcron/fcron.deny et /etc/fcron/fcron.allow. La manière la plus sûre est d'interdire tout les utilisateurs dans un premier temps dans /etc/fcron/fcron.deny , puis d'autoriser explicitement des utilisateurs dans /etc/fcron/fcron.allow .

Important
Si, ni /etc/fcron/fcron.allow ni /etc/fcron/fcron.deny n'existent alors tous les utilisateurs du groupe cron seront autorisés à utiliser crontab. fcron est fourni avec fcron.allow par défaut, ce qui autorise tous les utilisateurs du groupe cron à accéder à fcrontab .
CODE Autorisations dans fcron.deny
all

Si l'utilisateur wepy doit être capable de programmer ses propres tâches cron, l'ajouter à /etc/fcron/fcron.allow comme ceci :

CODE Autorisations dans fcron.allow
wepy

cronie

Si vixie cron ou cronie ont été choisis, éditer simplement le fichier /etc/fcron/fcron.allow.

Important
Il est important de noter que si seul /etc/cron.allow existe, alors seuls les utilisateurs du groupe cron qui y sont listés auront accès. Autrement, si seulement un fichier /etc/cron.deny vide existe, alors tous les utilisateurs du groupe cron seront autorisés. Ne pas laisser /etc/cron.deny vide si le fichier /etc/cron.allow n'existe pas.

Par exemple, pour donner accès à l'utilisateur wepy , l'ajouter à /etc/cron.allow de cette manière :

CODE Autorisations dans /etc/cron.allow
wepy

Programmer des tâches cron

Le processus pour éditer des crontabs est différent pour chacun des paquets, mais tous prennent en charge le même jeu de commandes de base ; ajouter et remplacer des crontabs, effacer des crontabs et lister les tâches cron dans les crontabs. La liste qui suit indique comment exécuter diverses commandes pour chacun des paquets.

Version Éditer la crontab Supprimer la crontab Nouvelle crontab Lister les tâches cron
dcron crontab -e crontab -d [user] crontab file crontab -l
fcron fcrontab -e fcrontab -r [user] fcrontab file fcrontab -l
vixie-cron, cronie & bcron crontab -e crontab -r -u [user] crontab file crontab -l
Remarque
Avec la commande remove, si aucun argument n'est transmis, la crontab courante de l'utilisateur est effacée.
Remarque
Fcron possède aussi un lien symbolique de crontab vers fcrontab.

Avant que ces commandes ne puissent être utilisées, il faut d'abord comprendre la crontab elle-même. Chacune des lignes dans une crontab comprend cinq champs de date/temps à documenter. Ils se présentent dans cette ordre : les minutes (0-59), les heures (0-23), les jours du mois (1-31), les mois (1-12) et les jours de la semaine (0-7, 1 correspond à lundi et 0 et 7 correspondent à dimanche). Les jours de la semaine et le mois peuvent être spécifiés en abrégé par trois lettres de cette manière : mon, tue, jan, feb, etc. Chacun des champs peut aussi spécifier une plage de valeurs (par exemple, 1-5 ou mon-fri), une liste de valeurs séparées par une virgule (par exemple, 1,2,3 ou mon,tue,wed) ou une plage de valeurs avec incrément (par exemple, 1-6/2 pour 1,3,5).

Cela peut sembler un peu compliqué, mais avec quelques exemples, il est facile de voir que ça ne l'est pas plus que ça.

CODE Exemples
## # Exécuter /bin/false toutes les  minutes durant toute l'année 
*     *     *     *     *        /bin/false
  
## # Exécuter /bin/false à 01:35 on les lundis, mardi, mercredi et le 4 de tous les mois
35    1     4     *     mon-wed  /bin/false
  
## # Exécuter /bin/true à 22:25 le 2 mars
25    22    2     3     *        /bin/true
  
## # Exécuter /bin/false à 02:00 chaque lundi, mercredi et vendredi 
0     2     *     *     1-5/2    /bin/false
Remarque
Bien noter comment les jours de la semaine et du mois doivent être spécifiés avant de les combiner. Si * est utilisé pour seulement l'un d'entre-eux, l'autre prend la priorité, tandis que * pour les deux signifie simplement tous les jours.

Pour mettre en pratique ce qui vient d'être appris jusqu'à maintenant, créer réellement quelques tâches cron. Tout d'abord, créer un fichier appelé crons.cron et lui donner cette allure :

FILE crons.cronCréer un fichier crons.cron
## #Mins  Hours  Days   Months  Day of the week
10     3      1      1       *       /bin/echo "I don't really like cron"
30     16     *      1,2     *       /bin/echo "I like cron a little"
*      *      *      1-12/2  *       /bin/echo "I really like cron"

Maintenant, ajouter cette crontab au système avec la commande de la colonne Nouvelle crontab tirée du tableau vu plus haut.

root #crontab crons.cron
Remarque
Les sorties de ces commandes ne seront pas vues tant qu'elles ne seront pas redirigées.

Pour vérifier les tâches cron programmées, utiliser la commande de la colonne Lister les tâches cron tirée du tableau vu plus haut.

root #crontab -l

Une liste ressemblant à crons.cron devrait s'afficher. Si ce n'est pas le cas, peut-être que la mauvaise commande a été utilisée pour entrer la nouvelle crontab.

Cette crontab devrait produire la sortie "I really like cron" toutes les minutes de chaque heure de chaque jour de tous les autres mois. Évidemment, un utilisateur ne voudra faire ça que s'il aime réellement cron. La crontab produira aussi la sortie "I like cron a little" à 16:30 tous les jours de janvier et février. Elle produira aussi "I don't really like cron" à 03:10 le premier janvier.

Si anacron est utilisé, continuer de lire cette section. Sinon, passer à la section suivante Éditer des crontabs

Les utilisateurs de Anacron pourront éditer /etc/anacrontab. Ce fichier comprend quatre champs : le nombre de jours entre deux lancements de commande, le temps de retard en minutes après lequel il lance la commande, le nom de la tâche et la commande à exécuter.

Par exemple, pour qu'il lance echo "I like anacron" tous les 5 jours, 10 minutes après le démarrage de anacron, écrire :

FILE /etc/anacrontab
5 10 wasting-time /bin/echo "I like anacron"

Anacron se termine après que toutes les tâches de anacrontab sont terminés. Pour vérifier si ces tâches doivent être exécutées tous les jours, utiliser un daemon cron. Les instructions à la fin de la prochaine section expliquent comment le faire.

Éditer des crontabs

Il faut être réaliste, aucun utilisateur ne souhaite que leur système leur dise combien ils aiment cron toutes les minutes. Pour faire encore un pas en avant, supprimer la crontab précédente en utilisant la commande de la colonne "Retirer la crontab" du tableau. Puis, utiliser la commande pour lister les tâches de cron correspondante pour vérifier que cela a marché.

root #crontab -d
root #crontab -l

Aucune tâches cron ne devrait être affichée dans la sortie de la commande crontab -l. Si des tâches sont affichées, cela signifie que la commande de suppression de la crontab a échouée. Vérifier alors que vous la bonne commande du tableau soit utilisée en fonction du paquet cron utilisé par le système.

Maintenant, placer quelque chose d'utile dans la crontab de root. La plupart des gens voudra exécuter updatedb toutes les semaines pour être certains que mlocate fonctionne correctement. Pour ajouter cela à la crontab du système, commencer par éditer crons.cron à nouveau pour qu'il contienne ce qui suit :

CODE Une crontab réelle
22 2 * * 1    /usr/bin/updatedb

Cela devrait faire que cron lance updatedb à 2:22 du matin, le lundi de chaque semaine. Maintenant, enregistrer la crontab avec la commande de la colonne Nouvelle crontab du tableau vu plus haut, et vérifier la liste à nouveau.

root #crontab crons.cron
root #crontab -l

Maintenant, supposer que emerge --sync doit être exécuté tous les jours afin de garder l'arbre portage à jour. Il est possible de le faire en commençant par éditer crons.cron puis en utilisant crontab crons.cron tout comme il a été fait jusqu'alors, ou en utilisant la commande appropriée issue de la colonne Editer une commande du tableau précédent. Ceci vous donne le moyen d'éditer la crontab utilisateur sur place, sans dépendre de fichiers externes comme crons.cron.

root #crontab -e

Cela devrait ouvrir la crontab utilisateur avec un éditeur. Par exemple si la commande emerge --sync doit être exécutée tous les jours à 6:30 du matin, lui donner le contenu suivant :

CODE Une crontab réelle
22 2 * * 1    /usr/bin/updatedb
30 6 * * *    /usr/bin/emerge --sync
## (Si anacron est utilisé, ajouter cette ligne)
30 7 * * *    /usr/sbin/anacron -s

Vérifier à nouveau la liste des tâches cron comme il a été fait dans les exemples précédents pour être certains que les tâches soient programmées. Si elles sont toutes là, tout va bien.

Utiliser cronbase

Comme mentionné plus haut, tous les paquets cron disponibles dépendent de sys-process/cronbase. Le paquet cronbase crée /etc/cron.{hourly,daily,weekly,monthly} et un script appelé run-crons. Noter que le fichier /etc/crontab par défaut contient quelque chose du genre :

CODE Crontab système par défaut
*/15 * * * *     test -x /usr/sbin/run-crons && /usr/sbin/run-crons
0  *  * * *      rm -f /var/spool/cron/lastrun/cron.hourly
0  3  * * *      rm -f /var/spool/cron/lastrun/cron.daily
15 4  * * 6      rm -f /var/spool/cron/lastrun/cron.weekly
30 5  1 * *      rm -f /var/spool/cron/lastrun/cron.monthly

Pour éviter d'entrer dans les détails, supposer simplement que ces commandes lanceront effectivement des scripts toutes les heures, tous les jours, toutes les semaines et tous les mois. Cette méthode de programmation de tâches cron a plusieurs avantages :

  • Elles seront exécutées même si l'ordinateur est arrêté au moment où elles devaient s'exécuter;
  • Il est facile pour les mainteneurs de paquets de placer des scripts à ces emplacements bien définis;
  • Les administrateurs savent exactement où la 'crontab et les tâches cron sont stockées , facilitant ainsi la sauvegarde et la restauration de cette partie du système.
Remarque
Il est utile de signaler à nouveau que vixie-cron et bcron lisent automatiquement /etc/crontab , tandis que dcron et fcron ne le font pas. Lire la section Les tables système pour en savoir plus à ce propos.

Utiliser anacron

Comme mentionné précédemment, anacron est utilisé sur des systèmes qui ne sont pas prévus pour tourner continuellement (comme la plupart des installation de PC de bureau). Son fichier de configuration par défaut est /etc/anacrontab. Il ressemble habituellement à ceci :

FILE /etc/anacrontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# format: period delay job-identifier command
1       5       cron.daily      run-parts /etc/cron.daily
7       10      cron.weekly     run-parts /etc/cron.weekly
30      15      cron.monthly    run-parts /etc/cron.monthly

La différente principale entre cela et d'autres crontabs, c'est qu'avec anacron, il n'y a pas de date/heure fixée pour la programmation de la tâche, mais seulement une période entre chacune des exécutions. Lorsque anacron est lancé, il vérifie le contenu d'un jeu de fichiers dans /var/spool/anacron et calcule si l'entrée correspondante dans le fichier de configuration a expiré depuis la dernière exécution. Si c'est le cas, la commande est invoquée de nouveau.

Comme dernier mot, il est important de neutraliser en les commentant toutes les entrées qui se recouvrent dans tous les autres cron installés sur le système, comme dans l'exemple suivant de crontab vixie-cron :

FILE /etc/crontab
# Pour vixie-cron
# $Header: /var/cvsroot/gentoo-x86/sys-process/vixie-cron/files/crontab-3.0.1-r4,v 1.3 2011/09/20 15:13:51 idl0r Exp $
  
# Variables Globales
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
  
# Vérifie les scripts dans cron.hourly, cron.daily, cron.weekly etcron.monthly
59  *  * * *    root    rm -f /var/spool/cron/lastrun/cron.hourly
#9  3  * * *    root    rm -f /var/spool/cron/lastrun/cron.daily
#19 4  * * 6    root    rm -f /var/spool/cron/lastrun/cron.weekly
#29 5  1 * *    root    rm -f /var/spool/cron/lastrun/cron.monthly
*/10  *  * * * root    test -x /usr/sbin/run-crons && /usr/sbin/run-crons @hourly root nice -n 19 run-parts --report /etc/cron.hourly
  1. Global variables

SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/

  1. check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly

59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly

  1. 9 3 * * * root rm -f /var/spool/cron/lastrun/cron.daily
  2. 19 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly
  3. 29 5 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly
    • /10 * * * * root test -x /usr/sbin/run-crons && /usr/sbin/run-crons

@hourly root test ! -e /var/spool/cron/lastrun/cron.hourly && touch /var/spool/cron/lastrun/cron.hourly && run-parts --report /etc/cron.hourly }}

Si ce n'est pas fait, les parties daily, weekly et montly seront exécutées - à des instants différents - à la fois par le démon cron et le démon anacron, conduisant à d'éventuelles double exécutions de tâches.

Dépannage

Si des problèmes sont rencontrer pour faire fonctionner cron correctement, cette courte liste de vérifications peut être utile.

Chacun des paquets cron est différent et l'étendue des fonctionnalités varie beaucoup. Se reporter absolument aux pages man sur crontab, fcrontab ou anacrontab, selon quel démon cron est utilisé.

Est-ce que cron est lancé ?

Exécuter ps ax | grep cron et s'assurer qu'il apparaît dans la liste des processus:

root #ps ax | grep cron

'/var/spool/cron/crontabs' is not a directory

Ensure that the user is in the "cron" group. Remember to log out and log; in order for the group changes to take effect. If that did not work, ensure that the username is in /etc/cron.allow. And if that didn't work, set crontab to be suid root.

root #chmod u+s /usr/bin/crontab

Est-ce que cron fonctionne correctement ?

Essayer ceci :

CODE crontab pour vérifier que cron fonctionne
* * * * * /bin/echo "foobar" >> /un_fichier

Puis vérifier que /un_fichier est modifié régulièrement.

Est-ce que la commande fonctionne ?

Comme précédemment, mais peut-être est-il nécessaire de rediriger la sortie d'erreur standard aussi :

CODE crontab pour vérifier que l'application fonctionne
* * * * * /bin/echo "foobar" >> /un_fichier 2>&1

Est-ce que cron lance la tâche ?

Jeter un coup d'œil au journal de cron , ordinairement /var/log/cron.log ou /var/log/messages pour les erreurs.

Y-a-t-il des dead.letters?

cron envoie généralement un courriel quand il y a un problème ; vérifier le courriel et rechercher également la création de fichiers ~/dead.letter.

Pourquoi les mails cron ne sont-ils pas envoyés ?

Afin de recevoir des mails de cron, une configuration MTA valide doit être implémentée. Cela est fourni par n'importe quel paquet de virtual/mta.

Si les courriels cron ne sont envoyés que localement, et non via un serveur de courriel entièrement configuré, le système peut utiliser les courriels mbox (/var/spool/mail), en activant l'option de la variable USE [2] pour le paquet fournissant le MTA.

External resources


This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Brown, Xavier Neys,
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.