* * * * *Champs
| Minute | * | toutes |
|---|---|---|
| Heure | * | toutes |
| Jour du mois | * | toutes |
| Mois | * | toutes |
| Jour de la semaine | * | toutes |
Où l’utiliser
| crontab | * * * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "* * * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "* * * * *" |
crontab utilise le fuseau horaire du serveur ; GitHub Actions utilise toujours UTC.
Bon à savoir
La minute est la résolution la plus fine qu’offre le cron standard ; pour aller plus vite, utilisez une boucle dans le script, une deuxième entrée commençant par sleep 30, ou un timer systemd. Le principal piège est le chevauchement : si une exécution dure plus d’une minute, les copies s’accumulent. Encapsulez la tâche dans flock, par exemple flock -n /tmp/job.lock /path/to/script.sh, pour qu’une nouvelle exécution s’arrête tant que la précédente est encore en cours.
Cron s’exécute avec un environnement minimal : PATH se limite généralement à /usr/bin:/bin, aucun profil de shell n’est chargé et le dossier de travail est votre dossier personnel, alors utilisez des chemins absolus. La sortie est envoyée par e-mail à l’utilisateur ou ignorée : redirigez-la avec >> /var/log/job.log 2>&1 et mettez en place une rotation de ce log. GitHub Actions ne s’exécutera pas aussi souvent : son intervalle minimal est de 5 minutes. Une alternative plus douce est */2, toutes les deux minutes.