Configuration des emplois Cron

Cron est un aspect souvent confus et mal configuré du système d'exploitation. Techniquement, cron est juste le démon de l'horloge (/usr/sbin/cron ou peut-être /usr/sbin/crond) qui exécute des commandes à des moments précis. Cependant, une poignée de fichiers et de programmes de configuration entrent dans la composition du paquet cron. Comme beaucoup de processus système, cron ne finit jamais.

Les fichiers de contrôle de cron sont les tables de cron ou les crontabs. Les crontabs sont souvent situés dans /var/spool/cron/crontab. Cependant, sur SuSE vous les trouverez dans /var/spool/cron/tabs. Les noms des fichiers de ce répertoire sont les noms des utilisateurs qui soumettent les tâches de cron.

Contrairement aux autres dialectes UNIX, le démon cron Linux ne dort pas avant que le prochain travail cron soit prêt. Au lieu de cela, quand cron termine un travail, il continuera de vérifier une fois par minute pour plus de travaux à exécuter. De plus, vous ne devriez pas modifier les fichiers directement. Vous pouvez les éditer avec un éditeur de texte comme vi, bien qu'il y ait le potentiel pour gâcher les choses. Par conséquent, vous devriez utiliser l'outil que Linux fournit : crontab. (voir la page homme pour plus de détails)

L'utilitaire crontab a plusieurs fonctions. C'est le moyen par lequel les fichiers contenant les tâches de cron sont soumis au système. Deuxièmement, il peut énumérer le contenu de votre crontab. Si vous êtes root, il peut aussi soumettre et lister des tâches pour n'importe quel utilisateur. Le problème est que les emplois ne peuvent pas être soumis individuellement. En utilisant le crontab, vous devez soumettre tous les emplois en même temps.

Au début, ça pourrait sembler un peu ennuyeux. Cependant, regardons le processus d'"adjoindre" un emploi. Pour ajouter une tâche cron, vous devez d'abord énumérer le contenu du crontab existant avec l'option -l. Si vous êtes root et souhaitez ajouter quelque chose à la crontab d'un autre utilisateur, utilisez l'option -u suivie du nom de l'utilisateur. Redirigez ensuite ce crontab vers un fichier que vous pouvez ensuite éditer. (Notez que sur certains systèmes crontab a -e (pour "modifier"), qui fera tout le travail pour vous. Voir la page homme pour plus de détails.)

Par exemple, permet de dire que vous êtes l'utilisateur racine et que vous voulez ajouter quelque chose au crontab de l'utilisateur UUCP. D'abord, obtenez la sortie de l'entrée crontab existante avec cette commande :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Pour ajouter une entrée, il suffit d'inclure une nouvelle ligne. Enregistrez le fichier, sortez de votre éditeur, et lancez l'utilitaire Crontab à nouveau. Cette fois, omettez le -l pour lister le fichier, mais incluez le nom du fichier. L'utilitaire crontab peut également accepter les entrées de stdin, de sorte que vous pouvez laisser le nom du fichier et crontab vous permettrait d'entrer les cronjobs sur la ligne de commande. Gardez à l'esprit que tout crontab précédent est supprimé quelle que soit la méthode que vous utilisez.

Le fichier /tmp/crontab.uucp contient maintenant le contenu de UUCPs crontab. Ça pourrait ressembler à ça.

39,9 * * * * /usr/lib/uucp/uudemon.heure > /dev/null
10 * * * * /usr/lib/uucp/uudemon.poll > /dev/null
45 23 * * * ulimite 5000; /usr/lib/uucp/uudemon.clean > /dev/null
48 10,14 * * 1-5 /usr/lib/uucp/uudemon.admin > /dev/null

Malgré son apparence, chaque entrée de crontab ne comporte que six champs. Les cinq premiers représentent le temps que l'emploi doit être exécuté et le sixième est la commande réelle. Les cinq premiers champs sont séparés par un espace ou un onglet et représentent les unités suivantes, respectivement:

minutes (0-59)
heure (0-23)
jour du mois (1-31)
mois de l'année (1-12)
jour de la semaine (0-6, 0=dimanche)
Pour spécifier toutes les valeurs possibles, utilisez un astérisque (*). Vous pouvez spécifier une seule valeur simplement en incluant cette seule valeur. Par exemple, la deuxième ligne de l'exemple précédent a une valeur de 10 dans le premier champ, soit 10 minutes après l'heure. Parce que tous les autres champs de quatre temps sont astérisques, cela signifie que la commande est exécutée toutes les heures de chaque jour à 10 minutes au-delà de l'heure.

Les plages de valeurs sont composées de la première valeur, d'un tiret et de la valeur finale. Par exemple, la quatrième ligne a une portée (1-5) dans la colonne du jour de la semaine, ce qui signifie que la commande n'est exécutée que les jours 1-5, du lundi au vendredi.

Pour spécifier différentes valeurs qui ne sont pas dans une plage, séparer les valeurs individuelles par une virgule. Dans le quatrième exemple, le champ heure a les deux valeurs 10 et 14. Cela signifie que le commandement est exécuté à 10 h et 14 h.

Notez que les temps sont additifs. Voyons un exemple :


10 * 1,16 * 1-5 /usr/local/bin/command


Le commandement est exécuté 10 minutes après chaque heure, la première et la seizième, ainsi que du lundi au vendredi. Si le premier ou le seizième était un week-end, le commandement continuerait à fonctionner parce que le jour du mois de champ s'appliquerait. Cependant, cela ne signifie pas que si le premier est un lundi, la commande est exécutée deux fois.

L'entrée de crontab peut être définie pour fonctionner à des intervalles différents de toutes les heures ou de tous les jours. La granularité peut être spécifiée toutes les deux minutes ou toutes les trois heures sans avoir à placer chaque entrée individuelle dans le crontab.

Disons que nous voulions exécuter la commande précédente non pas à 10 minutes après l'heure, mais toutes les 10 minutes. On pourrait faire une entrée qui ressemblait à ça.


0,10,20,30,40,50 * 1,16 * 1-5 /usr/local/bin/command


Cela se déroule toutes les 10 minutes : en haut de l'heure, 10 minutes après, 20 minutes après, et ainsi de suite. Pour faciliter la vie, nous pourrions simplement créer l'entrée comme ceci:


*/10 * 1,16 * 1-5 /usr/local/bin/command


Cette syntaxe peut être nouvelle pour certains administrateurs. (C'était pour moi.) La barre oblique (/) indique que dans l'intervalle spécifique (dans ce cas, chaque minute), exécutez la commande toutes les tant de minutes; dans ce cas, toutes les 10 minutes.

Nous pouvons également utiliser cela même lorsque nous définissons une plage. Par exemple, si le travail devait se dérouler entre 20 minutes après l'heure et 40 minutes après l'heure, l'entrée pourrait ressembler à ceci :


20-40 * 1,16 * 1-5 /usr/local/bin/command


Et si vous vouliez qu'il coure à cette heure, mais seulement toutes les trois minutes ? La ligne pourrait ressembler à ceci:


20-40/3 * 1,16 * 1-5 /usr/local/bin/command


Pour compliquer encore plus les choses, on peut dire que vous vouliez que le commandement s'exécute toutes les deux minutes entre l'heure et 20 minutes après, toutes les trois minutes entre 20 et 40 minutes après, puis toutes les 5 minutes entre 40 minutes après et l'heure.


,20/2,21-40/3,41-59/5 * 1,16 * 1-5 /usr/local/bin/command


Une chose vraiment agréable que beaucoup de dialectes Linux font est de vous permettre de spécifier des abréviations pour les jours de la semaine et les mois. C'est beaucoup plus facile de se rappeler que fri est pour vendredi au lieu de 5.

À l'exception de certaines erreurs dans les champs de temps, les erreurs ne sont pas signalées avant que cron n'exécute la commande. Tous les messages d'erreur et la sortie sont envoyés par la poste aux utilisateurs. C'est ce que dit la page homme de crontab et c'est fondamentalement vrai. Cependant, comme vous le voyez dans les exemples précédents, vous redirigez stdout vers /dev/null. Si vous le vouliez, vous pourriez aussi rediriger stderr là-bas et vous ne verriez jamais s'il y avait des erreurs.

La sortie est envoyée par la poste à l'utilisateur parce qu'il n'y a pas de véritable terminal sur lequel les cronjobs sont exécutés. Par conséquent, il n'y a pas d'écran pour afficher les erreurs. De plus, il n'y a pas de clavier pour accepter les entrées. Cela signifie-t-il que vous ne pouvez pas donner de commentaires à un travail de cron? - Non, c'est pas vrai. Repensez à la discussion sur les scripts shell. On peut redéfinir stdin, stdout et stderr. De cette façon, ils peuvent tous pointer vers des fichiers et se comporter comme nous nous attendons.

Une chose que je voudrais souligner est que je ne préconise pas de faire de la redirection dans le champ de commande du crontab. J'aime faire aussi peu que possible. Au lieu de cela, j'ai mis le chemin absolu vers un script shell. Je peux ensuite tester l'entrée du crontab avec quelque chose de simple. Une fois que cela fonctionne, je peux apporter des modifications au script shell sans avoir à soumettre à nouveau le cronjob.

Gardez à l'esprit que le cron n'est pas exact. Il se synchronise au sommet de chaque minute. Sur un système occupé dans lequel vous perdez des tiques d'horloge, les tâches ne peuvent être exécutées que quelques minutes après l'heure prévue. De plus, il peut y avoir d'autres processus avec des priorités plus élevées qui retardent les emplois de cron. Dans certains cas, (en particulier sur des systèmes très occupés), les travaux pourraient se solder par des arrêts de travail s'ils sont exécutés à chaque minute.

L'accès à l'installation de cron est autorisé par deux fichiers, tous deux dans /etc. Si vous avez un fichier cron.allow, vous pouvez spécifier quels utilisateurs sont autorisés à utiliser cron. Le cron.deny dit qui n'est pas autorisé à utiliser le cron. Si aucun des deux fichiers n'existe, seuls les utilisateurs du système ont accès. Cependant, si vous voulez que tout le monde ait accès, créez un fichier cron.deny d'entrée. En d'autres termes, personne ne se voit refuser l'accès.

Il est souvent utile pour root d'exécuter des tâches en tant qu'utilisateur différent sans avoir à changer d'utilisateur (par exemple, en utilisant la commande su). La plupart des dialectes Linux fournissent un mécanisme sous la forme du fichier /etc/crontab. Ce fichier n'est généralement enregistrable que par racine et dans certains cas, seule racine peut le lire (ce qui est souvent nécessaire dans des environnements de haute sécurité). La syntaxe générale est la même que les crontabs standards, à quelques exceptions près.

La première différence est l'en-tête, que vous pouvez voir ici :


COUVERTURE
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=racine
#
# vérifier les scripts en heure, jour, semaine et mois
#

59 * * * * racine rm -f /var/spool/cron/lastrun/cron.heure
14 0 * * * racine rm -f /var/spool/cron/lastrun/cron.day
29 0 * * 6 racines rm -f /var/spool/cron/lastrun/cron.hebdomadaire
44 0 1 * * racine rm -f /var/spool/cron/lastrun/cron.mensuel

La variable SHELL définit le shell sous lequel chaque commande va s'exécuter. La variable PATH est comme la variable d'environnement normale PATH et définit le chemin de recherche. La variable MAILTO indique qui devrait obtenir des messages de courriel, qui comprend les messages d'erreur et la sortie standard de la commandes exécutées.

La structure des entrées réelles est à peu près la même, à l'exception du nom d'utilisateur (root dans chaque cas ici). De cette façon, les utilisateurs root (ou qui peut éditer /etc/crontab) peuvent définir quel utilisateur exécute la commande. Gardez à l'esprit que cela peut être un gros trou de sécurité. Si quelqu'un peut écrire dans ce fichier, il peut créer une entrée qui fonctionne comme racine et a donc le contrôle complet du système.

La commande suivante dans la suite du cron est à. Sa fonction est exécuter une commande à un moment précis. La différence est qu'une fois le travail exécuté, il disparaît du système. Quant à Cron, deux dossiers, at.allow et at.deny, ont le même effet sur le programme.

La commande batch est également utilisée pour exécuter des commandes une fois. Cependant, les commandes soumises avec batch sont exécutées lorsque le système se rapproche, ce qui signifie que le système est moins occupé, par exemple, au milieu de la nuit. Il est possible que de tels emplois soient répartis sur toute la journée, en fonction de la charge du système.

Une chose à noter est le comportement de at et batch. Les deux acceptent les noms des commandes depuis la ligne de commande et non pas comme arguments pour la commande elle-même. Vous devez d'abord exécuter la commande à apporter à une nouvelle ligne, où vous entrez les commandes que vous voulez exécuter. Après chaque commande, appuyez sur Entrée. Lorsque vous avez terminé, appuyez sur Ctrl-D.

Comme ces deux commandes acceptent les commandes de stdin, vous pouvez entrer la commande sans devoir le faire sur une nouvelle ligne à chaque fois. Une possibilité est pour rediriger l'entrée d'un fichier. Par exemple


à l'heure actuelle +1 < command list


où command list est un fichier contenant une liste de commandes. Vous pourriez aussi avoir à (ou en lot) comme l'extrémité d'un tuyau


commande list cat à l'heure actuelle + 1 heure

cat command list , lot de commandes

Une autre chose intéressante à propos de la fois à et batch est qu'ils créent une sorte de script shell pour exécuter votre commande. Lorsque vous lancez à ou par lots, un fichier est créé dans /usr/spool/cron/atubs. Ce fichier contient les variables système que vous auriez normalement définies, ainsi que d'autres informations contenues dans /usr/lib/cron.proto. Cela crée essentiellement un environnement comme si vous vous étiez connecté.