Doc Gestion Crontab

Vous avez la possibilité d’avoir des tâches planifiées sur votre serveur.

Vous devez pouvoir vous connecter en SSH à votre serveur dédié (directement ou via un VPN ou un bastion). Si ce n’est pas le cas, merci de nous ouvrir un ticket.

Utilisation

Vous devez vous connecter en SSH avec l’utilisateur qui va lancer les tâches planifiées.

La commande crontab

Cette commande permet de gérer les tâches planifiées.

Pour ajouter/modifier/supprimer des tâches planifiées :

$ crontab -e

Pour lister les tâche planifiées :

$ crontab -l

Attention : Méfiez-vous de la touche r qui est proche de la touche e sur un clavier Azerty/Qwerty car crontab -r efface définitivement toutes les tâches planifiées !

Syntaxe

On peut s’aider de crontab guru pour être sûr de ne pas faire d’erreur sur l’horaire.

Voici la syntaxe de base :

minutes heures jours mois jour/semaine commande

n peut utiliser * pour toutes les occurrences (tous les jours, ou toutes les heures, etc.). On peut également utiliser des listes à virgule (3,5,7) ainsi des intervalles (2-6) ; on peut aussi avoir des intervalles réguliers (*/15).

Exemples de crontab :

0,30,45,51 * * * * /usr/local/adm/send-data
*/15 * * * * /usr/local/adm/check-nis 1>/dev/null 2>&1
00 01 * * * nice -10 find /inf -name core -exec rm -f {} \;
10 03 * * 1-6 nice -10 /usr/local/adm/sauvegarde-daily
30 05 * * 0 /usr/local/adm/savelog-weekly
30 06 1 * * /usr/local/adm/savelog-monthly
00 00 1 1 * /usr/local/bin/happy-new-year
@daily /usr/local/bin/minuit-check

On peut utiliser les mots clés @hourly/@daily/@weekly/@monthly pour lancer à la première minute de chaque heure/jour/semaine/mois mais c’est déconseillé car il vaut mieux répartir sur des heures différentes les différents scripts.

Attention, la moindre erreur de syntaxe risque de suspendre l’ensemble des tâches planifiées ! En cas de doute, ouvrez-nous un ticket.

Les Variables

Plusieurs variables peuvent être utilisées dans une crontab :

PATH : redéfinir le PATH des commandes lancés

SHELL : remplacer le shell /bin/sh utilisé par défaut par /bin/bash par exemple

MAILTO : Un email est envoyé à l’utilisateur lorsqu’une commande génère une sortie (stdout/stderr). On peut changer le destinataire ainsi qu’en mettre plusieurs ou empêcher l’envoi d’un message avec MAILTO="".

Ces variables peuvent être définies plusieurs fois, notamment MAILTO qui pourra précéder chaque ligne de cron :

MAILTO=jdoe@example.com,alert@example.com
@daily df -h
MAILTO=""
@hourly systemctl restart javajob
MAILTO=alert@example.com
@weekly /usr/local/bin/security-check

Sortie de vos scripts

Si votre commande ou script renvoie une sortie sur stdout ou stderr elle sera envoyée par email. Nous vous conseillons d’utiliser la variable MAILTO pour forcer l’envoi vers une adresse email précise (cf ci-dessus). Si vous ne recevez pas d’email, merci de nous ouvrir un ticket.

Attention, le changement de MAILTO concerne TOUS les scripts lancés après le changement de cette variable.

De façon générale, votre script ne devrait rien renvoyer sur stdout cf conseils ci-dessous.

Conseils pour vos scripts en crontab

• Un script en crontab devrait renvoyer ses erreurs sur stderr
• Un script en crontab ne doit renvoyer sur stderr qu’en cas d’erreur
• Un script en crontab ne doit pas rediriger stderr dans un fichier (exemples à ne pas reproduire: 2> cron_err.log ou > cron_err.log 2>&1)
• Un script en crontab ne doit rien renvoyer sur stdout
• Un script en crontab devrait être lancé avec une option -quiet ou -cron, permettant de le lancer en mode interactif sans cette option et d’obtenir des informations (sur stdout)
• Un script en crontab ne devrait pas faire de requête en curl/wget sur localhost … surtout si le script demande beaucoup de ressources ! L’utilisation d’un langage CLI est conseillé. [PHP] Dans le cas de PHP, il faut par exemple utiliser PHP CLI (qui a souvent des limitations moins restrictives qu’en mode web)
• Un script doit être lancé dans lancé dans la crontab de l’utilisateur, JAMAIS EN ROOT
• Au niveau des droits, un script en crontab doit avoir des permissions uniquement en 600 (lecture et écriture)
• Un script en crontab ne devrait pas être lancé à la minute 0, et surtout pas à 00h00 car trop de tâches sont susceptibles d’être lancées à des heures « piles »

FAQ

Changement d’heure

Lors d’un changement d’heure d’été ou d’hiver en France où un script est planifié pour être exécuté entre 2h et 3h du matin, théoriquement il peut être lancé deux fois ! En fait, sur les serveurs récents, le service de tâches planifiés sait détecter ce souci mais par précaution on évite d’en établir durant cette tranche horaire.

Échappement de caractères

Prenons l’exemple d’une copie horodatée de /foo chaque heure :

@hourly tar -cf foo-$(date +%H).tar foo

Celle-ci ne sera pas exécutée car le caractère % est interprété comme un saut de ligne où la commande sera incomplète et donc non fonctionnelle.

La correction s’applique en échappant le % avec un \ :

@hourly tar -cf foo-$(date +\%H).tar foo/