Vérificateur crontab : fichier entier et fuseau horaire

Que fait le vérificateur de crontab ?

Il prend ce que cron lit vraiment sur ton serveur : le fichier entier. Lignes de commentaire, lignes vides, affectations comme CRON_TZ=, PATH= et MAILTO=, la planification et la commande derrière. Rien de tout cela ne doit être découpé au préalable. Chaque ligne entrante devient une ligne de résultat : la planification en clair, la prochaine exécution dans le fuseau qui vaut pour cette ligne précise, et les avis qui vont avec.

Le vérificateur tourne entièrement dans ton navigateur. Pas d’envoi, pas de serveur, pas de mur de cookies. Pour une crontab ce n’est pas un point secondaire, car le fichier nomme des hôtes, des chemins de scripts, des noms de bases et de temps en temps un mot de passe que quelqu’un a tapé dans une ligne de commande parce que ça devait aller vite.

Pourquoi un vérificateur d’expression isolée ne suffit-il pas ?

Parce que les erreurs intéressantes vivent entre les lignes. Une expression se consulte en quelques secondes, et il existe de bons outils pour ça. Aucun ne répond aux questions qu’on se pose vraiment devant une crontab héritée. La même chose est-elle planifiée deux fois ? La sauvegarde entre-t-elle en collision avec l’export ? Le CRON_TZ du haut couvre-t-il encore la ligne du bas ? Et pourquoi aucun courriel n’arrive plus depuis le déménagement du serveur ?

Ce sont des propriétés du fichier, pas de l’expression. Recopier une crontab ligne par ligne dans un champ d’une seule ligne montre chaque ligne isolée et, précisément pour cette raison, aucune de ces questions. Le vérificateur inverse l’ordre : le fichier d’abord, la ligne ensuite.

Que se passe-t-il quand plusieurs tâches démarrent à la même minute ?

Elles se partagent tout. Processeur, disque, réseau et le plus souvent la même base de données. Le cas classique ressemble à ceci.

0 0 * * * /usr/local/bin/backup-db.sh
0 0 * * * /usr/local/bin/backup-files.sh
@daily    /usr/local/bin/rotate-logs.sh
0 0 * * 1 /usr/local/bin/weekly-report.sh
0 0 * * * /opt/app/bin/reindex.sh

Cinq lignes, quatre quotidiennes et une hebdomadaire. Le lundi à minuit, les cinq démarrent dans la même minute. Sur le papier c’est une planification, en pratique c’est un pic de charge. Et comme @daily ne se développe en rien d’autre que 0 0 * * *, un survol du fichier ne laisse même pas voir la collision.

Le vérificateur calcule les exécutions à venir de chaque tâche et les met côte à côte. Dès que plus d’une tombe sur le même instant, il le dit, avec la date concrète, les numéros de ligne concernés et le pire moment, celui où le plus de tâches démarrent ensemble. Comme il compare quand les choses tournent et non comment elles sont écrites, @daily contre 0 0 * * * et la tâche hebdomadaire contre les quotidiennes ressortent aussi.

Comment l’outil étale-t-il les heures de démarrage ?

D’un clic, sans toucher au reste du fichier. La première tâche de chaque collision garde sa minute, les autres se répartissent régulièrement sur l’heure. Les cinq lignes ci-dessus deviennent les minutes 0, 15, 35, 12 et 5, toujours à minuit, toujours le même jour, avec la même commande. Heure, jour et mois restent intacts.

Ensuite la proposition se contrôle elle-même. Le fichier réécrit est recalculé en entier. S’il reste un instant où deux tâches coïncident encore, elles sont décalées davantage jusqu’à ce que plus rien n’entre en collision. C’est seulement alors que le panneau annonce que ça tombe juste. Les lignes dont le champ de minute est une liste ou un pas ne sont pas déplacées automatiquement, car un décalage y changerait le sens ; elles sont nommées une à une pour que tu les regardes toi-même.

Le résultat est le fichier complet, prêt à copier, avec chaque commentaire et chaque affectation exactement là où ils étaient. Il repart directement dans crontab -e.

Quel fuseau horaire s’applique à une tâche cron ?

Celui du système, tant que rien ne dit le contraire. Ni UTC, ni celui du navigateur, ni celui qu’avait en tête la personne qui a écrit la ligne. Se tromper là-dessus donne une tâche censée tourner à six heures et qui tourne en fait à minuit, sans qu’aucune entrée de journal ne le laisse deviner.

Une ligne CRON_TZ=Europe/Paris change cela, mais seulement pour les lignes en dessous. Place-la au milieu du fichier et les tâches au-dessus continuent dans le fuseau du système. Le vérificateur applique exactement ça : il retient le dernier fuseau vu en descendant dans le fichier et calcule chaque ligne dedans. Les lignes d’un autre fuseau le portent visiblement, et l’aperçu compte combien de fuseaux distincts un fichier contient. Deux, c’est presque toujours un oubli.

S’y ajoute le changement d’heure. Quand l’horloge avance, une tâche placée dans l’heure sautée ne tourne pas du tout. Quand elle recule, elle tourne deux fois. Les deux sont des comportements documentés et non des bogues, mais presque personne ne le sait avant la première facturation en double.

Pourquoi cron ne trouve-t-il pas mon script ?

Parce que cron démarre dans un autre monde que ta session de connexion. Pas de .bashrc, pas de .profile, rien de l’environnement que pose ton déploiement, et un PATH qui, d’après crontab(5), ne contient en général que /usr/bin et /bin. Tout ce qu’un gestionnaire de versions, un gestionnaire de paquets ou ta propre compilation a déposé dans /usr/local/bin ou dans le répertoire personnel est hors de portée.

Le vérificateur signale chaque commande écrite sans chemin qui ne fait pas partie de cette dotation de base. tar et find ne reçoivent aucun avis, un cleanup écrit à la main si. S’il y a un PATH= en haut du fichier, l’avis se tait, parce que la condition est alors remplie.

Un second classique se cache dans la commande elle-même : le signe pourcent. Dans une crontab, ce signe n’est pas un caractère ordinaire. cron coupe la ligne à cet endroit et pousse le reste vers la tâche sur l’entrée standard. tar -czf backup-%Y.tgz devient tar -czf backup- et un fichier que personne ne cherche. Une barre oblique inverse devant règle le problème. Le vérificateur trouve l’endroit et compte correctement les barres, si bien qu’un pourcent déjà échappé ne déclenche pas de fausse alerte.

Où part la sortie d’une tâche cron ?

Dans le courriel, tant que tu ne dis rien d’autre. Si une tâche produit une sortie et qu’elle n’est pas redirigée, cron l’envoie au propriétaire de la crontab ou à l’adresse de MAILTO. Sur des serveurs sans envoi de courriel fonctionnel, elle disparaît donc, et personne ne s’en aperçoit.

Le vérificateur distingue trois états, parce que leurs conséquences diffèrent nettement. Pas de redirection et pas de MAILTO : chaque exécution envoie un courriel. MAILTO="" posé : la sortie est jetée, messages d’erreur compris. Redirigée vers > /dev/null 2>&1 : tout est silencieux, mais volontairement. Un 2>/dev/null seul ne compte pas comme redirection, car il fait uniquement taire les erreurs et laisse passer la vraie sortie, exactement l’inverse de ce qui était voulu.

Quelle est la différence entre crontab -l et /etc/crontab ?

La colonne utilisateur. Une crontab personnelle a cinq champs de temps puis directement la commande. Les fichiers système /etc/crontab et tout ce qui se trouve sous /etc/cron.d insèrent entre la planification et la commande une colonne portant le nom de l’utilisateur sous lequel la tâche doit tourner.

Copier une ligne de l’un vers l’autre produit une panne silencieuse. Dans une crontab personnelle, root devient simplement la commande, et cron essaie de lancer un programme nommé root. C’est pour cela que tu choisis le type de fichier en haut. En mode personnel, le vérificateur signale une ligne qui ressemble furieusement à une ligne portant encore une colonne utilisateur.

Que ne vérifie pas cet outil ?

Il ne voit pas ton serveur. Savoir si un script existe, s’il est exécutable, si l’utilisateur a les droits et si le service tourne seulement, personne ne peut y répondre d’ici. Le vérificateur travaille avec le texte que tu colles et avec rien d’autre.

Il ne surveille pas non plus les exécutions. Si tu veux savoir si une tâche a vraiment tourné cette nuit, il te faut une supervision sur le serveur, pas un outil dans un navigateur. Et il n’empêche pas une exécution d’en rattraper une autre : c’est le rôle d’un fichier de verrou dans le script. Ici tu reçois seulement l’avis qu’une tâche démarre assez souvent pour que cela arrive.

Pour les expressions isolées, pour Quartz, pour AWS EventBridge et pour l’export vers GitHub Actions ou un CronJob Kubernetes, il y a l’outil frère, le générateur d’expressions cron. Vérifier un fichier, c’est ici. Construire une ligne, c’est là-bas.