Comment planifier des tâches de routine avec Cron et Anacron sur un VPS

De Get Docs
Aller à :navigation, rechercher

Qu'est-ce que Cron ?

Cron est un utilitaire de planification qui vous permet d'attribuer des tâches à exécuter à des heures préconfigurées. Un outil de base, cron peut être utilisé pour automatiser presque tout sur votre système qui doit se produire à intervalles réguliers.

Aussi habile à gérer les tâches qui doivent être effectuées toutes les heures ou quotidiennement que les grandes routines qui doivent être effectuées une ou deux fois par an, cron est un outil essentiel pour un administrateur système.

Dans ce guide, nous verrons comment utiliser cron depuis la ligne de commande et comment lire son fichier de configuration. Nous explorerons également anacron, un outil qui peut être utilisé pour s'assurer que les tâches sont exécutées même lorsque le serveur est éteint une partie du temps.

Nous utiliserons un VPS Ubuntu 12.04, mais toute distribution Linux moderne devrait fonctionner de la même manière.

Comment fonctionne Cron

Cron est démarré au démarrage et s'exécute en arrière-plan en tant que démon. Cela signifie qu'il s'exécute sans interaction de l'utilisateur et attend que certains événements se produisent pour décider quand s'exécuter.

Dans le cas de cron, ces événements sont certains moments dans le temps. Cron s'exécute en arrière-plan et vérifie son fichier de configuration une fois par minute pour voir si un événement est programmé pour s'exécuter à cette minute.

Si un événement est planifié, cron exécute la commande prédéterminée qui lui a été donnée, puis revient en arrière-plan pendant une minute supplémentaire. Si aucun événement n'a été planifié, il attend 60 secondes et vérifie à nouveau.

En raison de cette programmation minute par minute, il est extrêmement flexible et configurable. Lors de l'installation de votre distribution, cron est déjà configuré pour exécuter diverses tâches.

Comment lire une crontab

Cron décide quelles commandes exécuter à quel moment en lisant une série de fichiers, chacun connu sous le nom de "crontab". Nous pouvons voir la crontab à l'échelle du système en regardant "/etc/crontab":

less /etc/crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Il s'agit de la crontab système et ne doit pas être modifiée dans la plupart des cas. La plupart du temps, il est préférable d'utiliser votre propre crontab. Le fichier système pourrait être remplacé dans une mise à jour et vos modifications seraient perdues.

Le fichier contient quelques parties intéressantes que nous devons comprendre.

Les deux premières lignes spécifient le shell qui exécutera les commandes répertoriées et le chemin à vérifier pour les programmes.

Le reste du fichier spécifie les commandes réelles et la planification. Les lignes de cette liste représentent chacune un enregistrement, ou ligne, dans une table. Le "tab" dans "crontab" signifie table. Chaque cellule du tableau est représentée par une colonne séparée par des espaces ou des tabulations.

La ligne commentée au-dessus du tableau donne un indice sur ce que chacune des colonnes représente :

# m h dom mon dow user  command

Planification des heures et des minutes avec Cron

La première colonne est la minute (0-59) de l'heure à laquelle la commande doit s'exécuter. La deuxième colonne est l'heure de la journée, de 0 à 23, à laquelle il doit s'exécuter. Un astérisque (*) signifie "toutes les valeurs possibles" et est utilisé comme caractère générique.

En combinant ces deux premières colonnes, nous pouvons obtenir une valeur temporelle pour la commande. Par exemple, la deuxième ligne du tableau a 25 dans la colonne des minutes et 6 dans la colonne des heures :

25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Cela signifie que la deuxième ligne devrait fonctionner à 6h25 du matin.

De même, la première ligne signifie que la commande doit être exécutée toutes les heures, 17 minutes après l'heure :

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly

Il sera donc exécuté à 1h17, 2h17, 3h17, etc.

Planifier des jours avec Cron

Les troisième, quatrième et cinquième colonnes déterminent les jours où la commande doit être exécutée. La troisième colonne spécifie un jour du mois, 1-31 (faites attention lors de la planification pour la fin du mois, car tous les mois n'ont pas le même nombre de jours).

La quatrième colonne spécifie quels mois, de 1 à 12, une commande doit être exécutée, et la cinquième colonne est réservée pour spécifier quel jour de la semaine une commande doit être exécutée, 0 et 7 signifiant tous deux dimanche. Ce dernier vous permet de programmer par semaine au lieu de par mois.

Si les colonnes du jour de la semaine et du jour du mois ont des valeurs qui ne sont pas des caractères génériques, la commande s'exécutera si l'une des colonnes correspond.

Les jours de la semaine et les mois peuvent également être spécifiés avec les trois premières lettres de leur nom. Nous pouvons également utiliser des plages avec des tirets (-) et sélectionner plusieurs valeurs avec des virgules (,).

Nous pouvons également spécifier un intervalle en suivant une valeur avec / et un nombre. Par exemple, pour exécuter la commande toutes les deux heures, nous pourrions placer "*/2" dans la colonne des heures.

Si nous regardons le crontab, vous verrez que le troisième enregistrement est exécuté tous les dimanches à 6h47 :

47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )

Le quatrième enregistrement est exécuté le premier du mois à 6h52 :

52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Utilisation de raccourcis horaires pour planifier

Vous pouvez remplacer les cinq premières colonnes de chaque enregistrement par un raccourci nommé si vous avez des exigences simples. La syntaxe pour ceux-ci est "@" suivi de l'intervalle nommé.

Par exemple, nous pouvons programmer quelque chose à exécuter chaque semaine en spécifiant "@weekly" au lieu de créer la configuration à cinq colonnes. Les autres choix sont "@annuel", "@mensuel", "@quotidien" et "@horaire".

Il existe également un raccourci spécial appelé "@reboot" qui s'exécute dès le démarrage de cron. Cela ne se produit généralement que lorsque le système démarre, c'est pourquoi il est appelé "reboot" au lieu de "cron-restart" ou quelque chose de similaire.

Gardez à l'esprit que ces raccourcis n'offrent pas de contrôle précis sur le moment où ils sont exécutés. Ils sont également tous configurés pour s'exécuter au premier moment possible de l'heure correspondante.

Par exemple, "@monthly" s'exécutera à minuit le premier du mois. Cela peut conduire à de nombreuses commandes programmées pour s'exécuter en même temps si elles tombent toutes en même temps. Vous ne pouvez pas échelonner ces événements comme vous le pouvez avec la syntaxe de planification conventionnelle.

Spécification des commandes et des utilisateurs avec Cron

Les colonnes suivantes concernent l'exécution réelle des commandes planifiées.

La sixième colonne, qui n'est présente que dans la crontab système que nous examinons, nomme l'utilisateur sous lequel la commande doit être exécutée.

La dernière colonne spécifie la commande réelle qui doit être exécutée. La commande peut contenir un signe de pourcentage (%), ce qui signifie que tout ce qui se trouve au-delà du premier signe de pourcentage est transmis à la commande en tant qu'entrée standard.

Chaque enregistrement doit se terminer par un caractère de nouvelle ligne. Ce n'est pas un problème pour la plupart des entrées, mais assurez-vous que vous avez une ligne vide après la dernière entrée, sinon la commande ne s'exécutera pas correctement.

Utilisation des run-parts et des répertoires Cron

Si vous regardez les commandes spécifiées dans la crontab système, vous verrez une mention de "anacron", dont nous parlerons plus tard, et de "run-parts".

La commande run-parts est une commande simple qui exécute chaque exécutable situé dans un répertoire spécifié. Il est largement utilisé avec cron car il vous permet d'exécuter plusieurs scripts à un moment précis en les plaçant à un seul endroit.

Cela a l'avantage de permettre à la crontab de rester propre et simple, et de vous permettre d'ajouter des scripts supplémentaires en les plaçant simplement ou en les liant au répertoire approprié au lieu d'ajuster la crontab.

Par défaut, la plupart des distributions configurent des dossiers pour chaque intervalle, où elles placent les scripts ou les liens vers les scripts qu'elles souhaitent exécuter à cet intervalle.

Par exemple, Ubuntu a des dossiers nommés "cron.daily", "cron.hourly", "cron.monthly" et "cron.weekly". À l'intérieur de ces dossiers se trouvent les scripts appropriés.

Utilisation de crontabs spécifiques à l'utilisateur

Maintenant que vous comprenez la syntaxe de cron, vous pouvez l'utiliser pour créer des tâches planifiées pour votre propre utilisateur. Nous pouvons le faire avec la commande "crontab".

Étant donné que les commandes de votre crontab s'exécuteront avec vos privilèges d'utilisateur, la colonne "utilisateur" n'existe pas dans les crontabs spécifiques à l'utilisateur.

Pour voir votre crontab actuel, tapez :

crontab -l

Vous n'en aurez probablement pas à moins que vous ne l'ayez spécifiquement créé à la main. Si vous avez une crontab, il est préférable de sauvegarder la copie actuelle avant de la modifier afin que toutes les modifications que vous apportez puissent être annulées.

Pour stocker votre sauvegarde dans un fichier appelé "cron.bak" dans votre répertoire personnel, exécutez :

crontab -l > ~/cron.back

Pour modifier votre crontab, tapez :

crontab -e
no crontab for demouser - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        
You might be given a selection prompt similar to the one above your first time using this command.  Select the editor you prefer to continue.
You will be dropped into a commented file that you can edit to create your own rules.
As a nonsensical example, if we wanted to echo the date into a file every 15 minutes every Wednesday, we could place this line into the file:
*/15 * * * 3 echo "$(date)" >> /home/demouser/file

We can then save the file and now, when we run "crontab -l", we should see the rule we just created:

crontab -l
. . .
. . .
*/15 * * * 3 echo "$(date)" >> /home/demouser/file

If you need to edit the crontab of a specific user, you can also add the "-u username" option. You will only be able to do this as root or with an account with administrative privileges.

For instance, if you would like to add something to the "root" crontab, you could issue:

sudo crontab -u root -e

Using Anacron with Cron

One of cron's biggest weaknesses is that it assumes that your server or computer is always on. If your machine is off and you have a task scheduled during that time, the task will never run.

This is a serious problem with systems that cannot be guaranteed to be on at any given time. Due to this scenario, a tool called "anacron" was developed. Anacron stands for anachronistic, and it is used compensate for this problem with cron.

Anacron uses parameters that are not as detailed as cron's options. The smallest increment that anacron understands is days. This means that anacron should be used to complement cron, not to replace it.

Anacron's advantage is that it uses time-stamped files to find out when the last time its commands were executed. This means, if a task is scheduled to be run daily and the computer was turned off during that time, when anacron is run, it can see that the task was last run more than 24 hours ago and execute the task correctly.

The anacron utility has a scheduling table just like cron does. It is appropriately named "anacrontab" and is located in the "/etc" directory as well. Let's see how it is formatted:

less /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# These replace cron's entries
1       5       cron.daily       nice run-parts --report /etc/cron.daily
7       10      cron.weekly      nice run-parts --report /etc/cron.weekly
@monthly        15      cron.monthly nice run-parts --report /etc/cron.monthly

We can see that it follows a similar format to the "crontab" files, but there are fewer columns and some noticeable differences.

The first column specifies how often the command should be run. It is given as an interval in days. A value of "1" will run every day, while a value of "3" will run every three days.

The second column is the delay to use before executing the commands. Anacron is not a daemon. It is run explicitly at one time. This field allows you to stagger execution so that not every task is running at the same time.

For example, the first line runs every day, five minutes after anacron is called:

1       5       cron.daily       nice run-parts --report /etc/cron.daily

The following line is run weekly (every 7 days), ten minutes after anacron is called:

7       10      cron.weekly      nice run-parts --report /etc/cron.weekly

The third column contains the name that the job will be known as in the anacron's messages and log files. The fourth field is the actual command that is run.

You can see that anacron is set to run some of the same scripts that are run by cron. Distributions handle this clash differently, by creating a preference for either cron or anacron and making the other program not execute the rule.

For instance, on Ubuntu, the "/etc/crontab" tests if anacron is available on the system, and only executes the scripts in the cron.* directories with cron if anacron is not found.

Other distributions have cron update the anacron's time-stamps every time it runs the contents of these directories, so that anacron does not execute when it is called.

Conclusion

Both cron and anacron are useful tools for when you need to automate processes. Understanding how to leverage their strengths and work around their weaknesses will allow you to utilize them easily and effectively.

Although the configuration syntax may be confusing at first, these tools will save you time in the long run and usually do not have to be adjusted often once you have a good working schedule.