Expressions cron : les cinq champs, avec exemples

Les cinq champs

Chaque ligne cron Unix standard commence par les cinq mêmes champs, suivis de la commande à exécuter.

* * * * *  command to run
| | | | |
| | | | +-- day of week  (0-7, 0 and 7 both mean Sunday, or SUN-SAT)
| | | +---- month        (1-12, or JAN-DEC)
| | +------ day of month (1-31)
| +-------- hour         (0-23)
+---------- minute       (0-59)

Un champ contient l'une de quatre choses : une étoile signifiant toutes les valeurs, un nombre unique, une liste, ou une plage. Les heures utilisent une horloge de 24 heures sans AM ni PM, donc 18h se note 18. Dimanche est à la fois 0 et 7 car différents systèmes ont historiquement divergé, et cron accepte les deux.

Certains ordonnanceurs ajoutent des champs. Quartz, utilisé par de nombreux frameworks Java, place un champ secondes en premier et ajoute une année optionnelle à la fin, donc une expression à six ou sept champs copiée depuis une référence Quartz ne fonctionnera pas dans un crontab Linux. Vérifiez pour quelle variante vous écrivez avant de copier une expression depuis n'importe quelle source.

Les caractères spéciaux

• * correspond à toutes les valeurs du champ. * * * * * s'exécute chaque minute.
• , liste des valeurs. 0 8,13,20 * * * s'exécute à 08h00, 13h00 et 20h00.
• - donne une plage. 0 9-17 * * * s'exécute chaque heure de 09h00 à 17h00.
• / prend un pas à travers une plage. */15 * * * * s'exécute aux minutes 0, 15, 30 et 45. Vous pouvez le combiner avec une plage : 0 9-17/2 * * * s'exécute à 9h, 11h, 13h, 15h et 17h.
• Les noms. MON à SUN et JAN à DEC fonctionnent dans les deux derniers champs et se lisent mieux que des nombres. Ils ne peuvent pas être utilisés à l'intérieur d'un pas.

Quatre autres caractères apparaissent constamment dans les tutoriels et n'existent pas dans cron standard. L pour le dernier jour, W pour le jour ouvré le plus proche, # pour le n-ième jour de la semaine du mois, et ? à la place d'une étoile sont des extensions Quartz. Une expression telle que 0 0 L * * sera rejetée par un crontab Linux. Pour exécuter quelque chose le dernier jour du mois là-bas, exécutez-le quotidiennement et laissez la commande décider :

0 0 * * * [ "$(date -d tomorrow +\%d)" = "01" ] && /usr/local/bin/month-end.sh

Remarquez les antislashs dans cette ligne. Un signe pourcentage a une signification spéciale dans un crontab, ce qui est la cinquième erreur ci-dessous.

Cron accepte aussi six chaînes abrégées à la place des cinq champs : @yearly (aussi écrit @annually), @monthly, @weekly, @daily (aussi @midnight), @hourly, et @reboot, qui s'exécute une fois au démarrage de cron plutôt que sur une horloge. @reboot n'est pas pris en charge partout.

Planifications courantes

Les erreurs qui placent la tâche au mauvais moment

1. Remplir les deux champs de jour. C'est celle qui piège tout le monde. Quand le jour du mois et le jour de la semaine sont tous deux définis à autre chose qu'une étoile, cron exécute la tâche quand l'un ou l'autre correspond, pas les deux à la fois. 0 0 13 * FRI s'exécute chaque 13 du mois et chaque vendredi, pas seulement le vendredi 13.
2. Un pas qui ne divise pas la plage. */7 * * * * se déclenche aux minutes 0, 7, 14, 21, 28, 35, 42, 49 et 56, puis recommence à 0. L'écart au passage de l'heure est de quatre minutes, pas sept. Le même piège s'applique à */40 dans le champ minute et à tout pas qui n'est pas un diviseur de 60.
3. Placer le pas dans le mauvais champ. */2 * * * * s'exécute toutes les deux minutes. 0 */2 * * * s'exécute toutes les deux heures. Oublier le 0 en tête transforme une tâche horaire en une tâche qui s'exécute 30 fois plus souvent.
4. Présumer de l'environnement. Cron donne à la tâche un environnement minimal, généralement guère plus que PATH=/usr/bin:/bin et SHELL=/bin/sh. Un script qui fonctionne dans votre shell échoue sous cron parce qu'il appelle quelque chose situé dans /usr/local/bin. Utilisez des chemins absolus pour la commande et à l'intérieur de celle-ci.
5. Un signe pourcentage non échappé. Dans un crontab, % est transformé en saut de ligne et tout ce qui suit le premier est transmis à la commande comme entrée standard. Un date +%Y-%m-%d à l'intérieur d'une ligne crontab doit s'écrire date +\%Y-\%m-\%d.
6. Ignorer la sortie. Tout ce que la tâche affiche est envoyé par e-mail au propriétaire du crontab, et sur une machine sans messagerie configurée, c'est simplement perdu. Envoyez-le quelque part où vous le lirez : 0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
7. Laisser les exécutions se chevaucher. Cron démarre l'exécution suivante selon le calendrier, que la précédente soit terminée ou non. Enveloppez les tâches longues dans un verrou : */5 * * * * flock -n /tmp/sync.lock /usr/local/bin/sync.sh
8. Oublier les changements d'heure. Cron utilise l'heure locale de la machine. Les jours où les horloges changent, l'heure autour de 02h00 soit n'existe pas, soit se produit deux fois, donc une tâche planifiée à l'intérieur peut être sautée ou exécutée deux fois selon l'implémentation de cron. Réglez les serveurs sur UTC, ou planifiez en dehors de cette fenêtre.
9. Taper crontab -r. Cela supprime tout le crontab sans confirmation, et cette commande se trouve à une touche de crontab -e. Conservez le crontab sous contrôle de version et installez-le depuis un fichier.

Vérifiez depuis l'extérieur

Une expression qui s'analyse correctement n'est pas la même chose qu'une tâche qui s'est exécutée. Vérifiez les deux, sur la machine puis depuis l'extérieur de celle-ci.

Sur la machine, confirmez ce qui est installé, ce que dit l'horloge, et si cron a lancé la tâche :

crontab -l
timedatectl
grep CRON /var/log/syslog | tail -20
journalctl -u cron -u crond --since "2 hours ago"

La ligne de journal prouve que cron a lancé la commande. Elle ne dit rien sur la réussite de la commande, ce qui explique pourquoi la redirection vers un fichier journal, mentionnée dans les erreurs ci-dessus, compte.

Ensuite, vérifiez le résultat comme le ferait un utilisateur, depuis l'extérieur du serveur. La plupart des tâches planifiées existent pour changer quelque chose d'observable : un flux qui devrait porter la date du jour, un sitemap qui aurait dû être réécrit, un export qui aurait dû apparaître. Demandez-le et lisez les en-têtes :

curl -sI https://example.com/exports/daily.json
curl -s https://example.com/health/last-run

L'en-tête Last-Modified vous indique si le fichier est frais, et il le fait sans accès shell. Exécuter la même requête depuis plusieurs emplacements avec la vérification HTTP distingue une tâche qui ne s'est pas exécutée d'une page mise en cache à une bordure dans une région et périmée seulement là-bas. Cette distinction est invisible depuis un seul curl exécuté sur le serveur lui-même.

Savoir quand une tâche planifiée cesse de s'exécuter

Une tâche cron qui cesse de s'exécuter ne produit rien à remarquer. Il n'y a ni page d'erreur ni requête échouée, donc rien ne déclenche d'alerte à moins que quelque chose ne surveille cette absence. Ce que vous surveillez, c'est l'effet de la tâche plutôt que la tâche elle-même : un fichier de statut qu'elle réécrit, un horodatage qu'elle publie, un point de terminaison qui rapporte sa dernière exécution réussie. Une vérification planifiée sur ce point de terminaison transforme un échec silencieux en notification, et HostTracker les envoie par e-mail, SMS, appel vocal, Slack, Telegram et bien plus à travers 13 types de moniteurs. La mécanique pour en mettre une en place se trouve dans le guide de la vérification HTTP, le reste des guides de dépannage se trouve dans la section Résoudre, et la liste complète des types de vérifications se trouve sur la page des fonctionnalités.