C’est une question canonique sur l’utilisation de cron & crontab.

Vous avez été dirigé ici car la communauté est à peu près certaine que la réponse à votre question se trouve ci-dessous. Si votre question ne répond pas ci-dessous, elle vous aidera à recueillir des informations qui aideront la communauté à vous aider. Cette information devrait être modifiée dans votre question initiale.

La réponse à ' Pourquoi ma crontab ne fonctionne-t-elle pas et comment puis-je la résoudre? 'peut être vu ci-dessous. Cela concerne le cronsystème avec la crontab en surbrillance.

Comment résoudre tous vos problèmes / problèmes liés à crontab (Linux)

Ceci est un wiki de communauté . Si vous remarquez quelque chose d’erreur avec cette réponse ou si vous avez des informations supplémentaires, veuillez le modifier.

Premièrement, la terminologie de base:

• cron (8) est le démon qui exécute les commandes planifiées.
• crontab (1) est le programme utilisé pour modifier les fichiers utilisateur crontab (5).
• crontab (5) est un fichier par utilisateur contenant des instructions pour cron (8).

Ensuite, éducation sur cron:

Chaque utilisateur d’un système peut avoir son propre fichier crontab. L'emplacement des fichiers crontab racine et utilisateur dépend du système, mais ils sont généralement situés en dessous /var/spool/cron.

Il existe un /etc/crontabfichier système, le /etc/cron.drépertoire peut contenir des fragments de crontab qui sont également lus et gérés par cron. Certaines distributions Linux (par exemple, Red Hat) ont également des /etc/cron.{hourly,daily,weekly,monthly}répertoires, des scripts dans lesquels seront exécutées toutes les heures / tous les jours / toutes les semaines / tous les mois, avec le privilège root.

root peut toujours utiliser la commande crontab; les utilisateurs réguliers peuvent ou non recevoir un accès. Lorsque vous éditez le fichier crontab à l'aide de la commande crontab -eet que vous l'enregistrez, crond le recherche pour une validité de base, mais ne garantit pas que votre fichier crontab est correctement formé. Il existe un fichier appelé cron.denyqui spécifie quels utilisateurs ne peuvent pas utiliser cron. L' cron.denyemplacement du fichier dépend du système et peut être supprimé, ce qui permettra à tous les utilisateurs d'utiliser Cron.

Si l'ordinateur n'est pas allumé ou si le démon crond n'est pas en cours d'exécution et que la date / heure d'exécution d'une commande est expirée, crond n'acceptera pas et n'exécutera pas les requêtes antérieures.

Détails crontab, comment formuler une commande:

Une commande crontab est représentée par une seule ligne. Vous ne pouvez pas utiliser \pour étendre une commande sur plusieurs lignes. Le #signe hash ( ) représente un commentaire qui signifie que tout ce qui est sur cette ligne est ignoré par cron. Les espaces et les lignes vierges sont ignorés.

Soyez très prudent lorsque vous utilisez le %signe percent ( ) dans votre commande. Sauf s'ils sont échappés, \%ils sont convertis en saut de ligne et tout ce qui suit le premier non-échappé %est transmis à votre commande sur stdin.

Il existe deux formats pour les fichiers crontab:

• Crontabs utilisateur

  # Example of job definition:
  # .---------------- minute (0 - 59)
  # |  .------------- hour (0 - 23)
  # |  |  .---------- day of month (1 - 31)
  # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
  # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
  # |  |  |  |  |
  # *  *  *  *  *   command to be executed
  

• Système /etc/crontabet /etc/cron.dfragments

  # Example of job definition:
  # .---------------- minute (0 - 59)
  # |  .------------- hour (0 - 23)
  # |  |  .---------- day of month (1 - 31)
  # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
  # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
  # |  |  |  |  |
  # *  *  *  *  * user-name  command to be executed
  

Notez que ce dernier nécessite un nom d'utilisateur. La commande sera exécutée en tant qu'utilisateur nommé.

Les 5 premiers champs de la ligne représentent le (s) moment (s) où la commande doit être exécutée. Vous pouvez utiliser des chiffres ou des noms de jours / mois, le cas échéant, dans la spécification de l'heure.

• Les champs sont séparés par des espaces ou des tabulations.
• Une virgule ( ,) est utilisée pour spécifier une liste, par exemple 1,4,6,8 qui signifie exécuter à 1,4,6,8.
• Les plages sont spécifiées par un tiret ( -) et peuvent être combinées avec des listes, par exemple 1-3,9-12, ce qui signifie entre 1 et 3, puis entre 9 et 12.
• Le /caractère peut être utilisé pour introduire une étape, par exemple 2/5, ce qui signifie à partir de 2, puis toutes les 5 (2,7,12,17,22 ...). Ils ne vont pas au-delà de la fin.
• Un astérisque ( *) dans un champ indique toute la plage de ce champ (par exemple, 0-59le champ des minutes).
• Les plages et les étapes peuvent être combinées, par exemple, */2signifie commencer au minimum pour le champ concerné, puis tous les 2, par exemple 0 pour les minutes (0,2 ... 58), 1 pour les mois (1,3 ... 11), etc.

Débogage des commandes cron

Vérifiez le mail!

Par défaut, cron enverra toute sortie de la commande à l'utilisateur sur lequel elle est exécutée. S'il n'y a pas de sortie, il n'y aura pas de courrier. Si vous voulez que cron envoie des messages à un autre compte, vous pouvez définir la variable d’environnement MAILTO dans le fichier crontab, par exemple:

MAILTO=user@somehost.tld
1 2 * * * /path/to/your/command

Capturez vous-même la sortie

Vous pouvez rediriger stdout et stderr vers un fichier. La syntaxe exacte pour capturer la sortie peut varier en fonction du shell utilisé par cron. Voici deux exemples qui enregistrent toutes les sorties dans un fichier dans /tmp/mycommand.log:

1 2 * * * /path/to/your/command &>/tmp/mycommand.log
1 2 * * * /path/to/your/command >/tmp/mycommand.log 2>&1

Regarde les bûches

Cron enregistre ses actions via syslog, qui (selon votre configuration) va souvent à /var/log/cronou /var/log/syslog.

Si nécessaire, vous pouvez filtrer les instructions cron avec, par exemple,

grep CRON /var/log/syslog 

Maintenant que nous avons passé en revue les bases de cron, où se trouvent les fichiers et comment les utiliser, examinons quelques problèmes courants.

Vérifiez que cron est en cours d'exécution

Si cron ne fonctionne pas, vos commandes ne seront pas planifiées ...

ps -ef | grep cron | grep -v grep

devrait vous obtenir quelque chose comme

root    1224   1  0 Nov16 ?    00:00:03 cron

ou

root    2018   1  0 Nov14 ?    00:00:06 crond

Si ce n'est pas le redémarrer

/sbin/service cron start

ou

/sbin/service crond start

Il peut y avoir d'autres méthodes; utilisez ce que votre distribution fournit.

cron exécute votre commande dans un environnement restreint.

Les variables d'environnement disponibles seront probablement très limitées. En règle générale, vous obtenez seulement quelques variables définies, telles que $LOGNAME, $HOMEet $PATH.

Il est à noter que le PATHest limité à /bin:/usr/bin. La grande majorité des problèmes "mon script cron ne fonctionne pas" sont causés par ce chemin restrictif . Si votre commande est dans un emplacement différent, vous pouvez résoudre ce problème de plusieurs manières:

1. Indiquez le chemin complet de votre commande.

   1 2 * * * /path/to/your/command
   

2. Fournissez un PATH approprié dans le fichier crontab

   PATH=/usr:/usr/bin:/path/to/something/else
   1 2 * * * command 
   

Si votre commande nécessite d'autres variables d'environnement, vous pouvez également les définir dans le fichier crontab.

cron exécute votre commande avec cwd == $ HOME

Peu importe où le programme que vous exécutez réside sur le système de fichiers, le répertoire de travail actuel du programme lors de son exécution par cron sera le répertoire de base de l'utilisateur . Si vous accédez aux fichiers de votre programme, vous devrez en tenir compte si vous utilisez des chemins relatifs, ou (de préférence), utilisez simplement des chemins pleinement qualifiés partout, ce qui évite à tout le monde beaucoup de confusion.

La dernière commande de ma crontab ne s'exécute pas

Cron nécessite généralement que les commandes soient terminées par une nouvelle ligne. Éditez votre crontab; allez à la fin de la ligne qui contient la dernière commande et insérez une nouvelle ligne (appuyez sur entrée).

Vérifier le format de la crontab

Vous ne pouvez pas utiliser une crontab utilisateur formatée par crontab pour / etc / crontab ou les fragments de /etc/cron.d et vice versa. Une crontab formatée par l'utilisateur n'inclut pas de nom d'utilisateur à la 6ème position d'une ligne, alors qu'une crontab formatée par le système inclut le nom d'utilisateur et exécute la commande en tant qu'utilisateur.

Je mets un fichier dans /etc/cron.{hourly,daily,weekly,monthly} et il ne s'exécute pas

• Vérifiez que le nom du fichier n’a pas d’extension voir run-parts
• Assurez-vous que le fichier dispose des autorisations d'exécution.
• Indiquez au système ce qu'il faut utiliser pour exécuter votre script (par exemple, mettre #!/bin/shen haut)

Bugs liés à la date de Cron

Si votre date est récemment modifiée par un utilisateur ou une mise à jour du système, un fuseau horaire ou autre, crontab commencera à se comporter de manière erratique et affichera des bugs bizarres, parfois fonctionnels, parfois non. C'est la tentative de crontab d'essayer de "faire ce que vous voulez" quand le temps change de dessous. Le champ "minute" deviendra inefficace après le changement d'heure. Dans ce scénario, seuls les astérisques seraient acceptés. Redémarrez cron et réessayez sans vous connecter à Internet (pour que la date ne puisse pas être réinitialisée sur l'un des serveurs de temps).

Encore des signes de pourcentage

Pour souligner le conseil relatif aux signes de pourcentage, voici un exemple de ce que cron en fait:

# cron entry
* * * * * cat >$HOME/cron.out%foo%bar%baz

créera le fichier ~ / cron.out contenant les 3 lignes

foo
bar
baz

Ceci est particulièrement intrusif lorsque vous utilisez la datecommande. Assurez-vous d'échapper aux signes de pourcentage

* * * * * /path/to/command --day "$(date "+\%Y\%m\%d")"

Debian Linux et ses dérivés (Ubuntu, Mint, etc.) présentent certaines particularités qui peuvent empêcher votre tâche cron de s’exécuter. en particulier, les fichiers dans /etc/cron.d, /etc/cron.{hourly,daily,weekly,monthly}doivent:

• être la propriété de root
• être seulement accessible en écriture par root
• ne pas être accessible en écriture par le groupe ou d'autres utilisateurs
• avoir un nom sans points "." ou tout autre caractère spécial sauf '-' et '_'.

Le dernier fait régulièrement mal aux utilisateurs peu méfiants; en particulier un script dans l' un de ces dossiers nommés whatever.sh, mycron.py, testfile.pl, etc. seront pas être exécuté, jamais.

D'après mon expérience, ce point particulier a été de loin la raison la plus fréquente pour laquelle un cronjob non exécuté sur Debian et ses dérivés.

Voir man cronpour plus de détails, si nécessaire.

Si vos tâches cron cessent de fonctionner, vérifiez que votre mot de passe n’est pas expiré. Depuis, tous les travaux cron s’arrêtent.
Il y aura des messages /var/log/messagessimilaires à celui ci-dessous qui montrent des problèmes d'authentification de l'utilisateur:

(username) FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)

Horaires peu communs et irréguliers

Cron est tout à fait considéré comme un ordonnanceur très basique et la syntaxe ne permet pas facilement à un administrateur de formuler des plannings légèrement plus rares.

Considérez le travail suivant qui serait généralement expliqué comme "exécuté commandtoutes les 5 minutes" :

*/5 * * * * /path/to/your/command

contre:

*/7 * * * * /path/to/your/command

qui ne toujours courir commandtoutes les 7 minutes .

Rappelez - vous que le /personnage peut être utilisé pour introduire une étape , mais que des mesures ne boucle pas au - delà de la fin d'une série par exemple , */7qui correspond à toutes les 7 minutes du procès - verbal 0-59 c. -à- 0,7,14,21,28,35,42,49, 56 mais entre une heure et la prochaine , il y aura seulement 4 minutes entre les lots , après 00:56une nouvelle série commence à 01:00, 01:07etc. (et les lots ne fonctionnera pas sur 01:03, 01:10, 01:17etc.).

Que faire à la place?

Créer plusieurs lots

Plutôt que de créer un seul travail cron, créez plusieurs lots qui, combinés, donnent le planning souhaité.

Par exemple, pour exécuter un lot toutes les 40 minutes (00:00, 00:40, 01:20, 02:00, etc.), créez deux lots, un qui s'exécute deux fois aux heures paires et un autre qui ne fonctionne qu'aux heures impaires:

# The following lines create a batch that runs every 40 minutes i.e.

# runs on   0:00, 0:40,        02:00, 02:40         04:00 etc to 22:40
0,40 */2 * * * /path/to/your/command

# runs on               01:20,               03:20,       etc to 23:20
20 1/2 * * * /path/to/your/command

# Combined: 0:00, 0:40, 01:20, 02:00, 02:40, 03:20, 04:00 etc.

Exécutez vos lots moins fréquemment

Plutôt que d'exécuter votre lot toutes les 7 minutes, ce qui est un programme difficile à décomposer en plusieurs lots, exécutez-le simplement toutes les 10 minutes.

Commencez vos lots plus souvent (mais empêchez l'exécution simultanée de plusieurs lots)

De nombreuses planifications étranges évoluent car les durées d'exécution des lots augmentent / fluctuent, puis les lots sont planifiés avec une marge de sécurité supplémentaire afin d'éviter que les exécutions ultérieures du même lot ne se chevauchent et ne s'exécutent simultanément.

Au lieu de cela, pensez différemment et créez un cronjob qui échouera normalement lorsqu'une exécution précédente n'est pas encore terminée, mais qui s'exécutera autrement. Voir ce Q & A :

* * * * * /usr/bin/flock -n /tmp/fcj.lockfile /usr/local/bin/frequent_cron_job 

Cela lancera presque immédiatement une nouvelle exécution une fois que la précédente exécution de / usr / local / bin / frequent_cron_job sera terminée.

Commencez vos lots plus souvent (mais quittez-les normalement lorsque les conditions ne sont pas bonnes)

La syntaxe cron étant limitée, vous pouvez décider de placer des conditions et une logique plus complexes dans le travail par lots lui-même (ou dans un script d'encapsulation autour du travail par lots existant). Cela vous permet d'utiliser les fonctionnalités avancées de vos langages de script préférés, de commenter votre code et d'empêcher les constructions difficiles à lire dans l'entrée de la crontab elle-même.

En bash, seven-minute-jobcela ressemblerait à quelque chose comme:

#!/bin/bash
# seven-minute-job
# This batch will only run when 420 seconds (7 min) have passed
# since the file /tmp/lastrun was either created or updated

if [ ! -f /tmp/lastrun ] ; then
    touch /tmp/lastrun
fi

if [ $(( $(date +%s) - $(date -r /tmp/lastrun +%s) )) -lt 420 ] ; then
     # The minimum interval of 7 minutes between successive batches hasn't passed yet.
    exit 0
fi

####  Start running your actual batch job below

/path/to/your/command

#### actual batch job is done, now update the time stamp
date > /tmp/lastrun
#EOF

Ce que vous pouvez alors en toute sécurité (tenter) de lancer toutes les minutes:

* * * * * /path/to/your/seven-minute-job

Un autre, mais le même problème serait de programmer un lot pour exécuter le premier lundi de chaque mois (ou le deuxième mercredi) , etc. programmer simplement le lot à tous les lundis et quitter lorsque la date est ni entre le 1 ^er ou 7 ^e et le jour de la semaine n'est pas lundi.

#!/bin/bash
# first-monday-of-the-month-housekeeping-job

# exit if today is not a Monday (and prevent locale issues by using the day number) 
if [ $(date +%u) != 1 ] ; then
  exit 0
fi

# exit if today is not the first Monday
if [ $(date +%d) -gt 7 ] ; then
  exit 0
fi

####  Start running your actual batch job below

/path/to/your/command

#EOF

Ce que vous pouvez ensuite (tenter) de lancer en toute sécurité tous les lundis:

0 0 * * 1 /path/to/your/first-monday-of-the-month-housekeeping-job

Ne pas utiliser cron

Si vos besoins sont complexes, vous pouvez envisager d’utiliser un produit plus avancé conçu pour exécuter des planifications complexes (réparties sur plusieurs serveurs) et prenant en charge les déclencheurs, les dépendances de tâches, la gestion des erreurs, les tentatives et la surveillance des tentatives, etc. " ordonnancement des travaux et / ou" automatisation de la charge de travail ".

Spécifique à PHP

Si vous avez un job cron comme:

php /bla/bla/something.php >> /var/logs/somelog-for-stdout.log

Et en cas d'erreurs, attendez-vous à ce qu'ils vous soient envoyés, mais ils ne le font pas - vérifiez ceci.

PHP par défaut n'envoie pas d'erreur à STDOUT. @see https://bugs.php.net/bug.php?id=22839

Pour résoudre ce problème, ajoutez dans le php.ini de cli`s ou dans votre ligne (ou dans votre wrapper bash pour PHP) ceux-ci:

• --define display_startup_errors = 1
• --define display_errors = 'stderr'

Le 1er réglage vous permettra d'avoir des fatals comme 'Memory Oops' et 2nd - de les rediriger tous vers STDERR. Ce n’est qu’après avoir bien dormi que tout sera envoyé au courrier de votre racine au lieu de simplement vous connecter.

Ajouter ma réponse à partir d'ici pour compléter, et ajouter une autre ressource potentiellement utile:

L' cronutilisateur a un différent $PATHde vous:

Un problème fréquent rencontré par les utilisateurs avec les crontabentrées est qu’ils oublient qu’il est cronexécuté de manière différente environmentde celle d’un utilisateur connecté. Par exemple, un utilisateur crée un programme ou un script dans son $HOMErépertoire et entre la commande suivante pour l'exécuter:

$ ./certbot ... 

La commande fonctionne parfaitement depuis sa ligne de commande. L'utilisateur ajoute ensuite cette commande à la sienne crontab, mais constate que cela ne fonctionne pas:

*/10 * * * * ./certbot ....

La raison de l'échec dans ce cas est que l' ./emplacement de l' cronutilisateur est différent de celui de l' utilisateur connecté. C'est, environmentc'est différent! Le PATH fait partie de la environment, et il est généralement différent pour l' cronutilisateur. Le problème est que le environmentfor cronn’est pas le même pour toutes les distributions * nix et qu’il existe plusieurs versions decron

Une solution simple à ce problème consiste à donner à l' cronutilisateur une spécification de chemin complète dans l' crontabentrée:

0 22 * * * /path/to/certbot .....

Quel est l' cronutilisateur environment?

Dans certains cas, nous pouvons avoir besoin de connaître la environmentspécification complète de cronnotre système (ou nous pouvons simplement être curieux). Quel est le environmentpour l' cronutilisateur, et en quoi est-il différent du nôtre? En outre, nous pouvons avoir besoin de connaître le environmentpour un autre cronutilisateur - rootpar exemple ... qu'est-ce que l' rootutilisateur environmentutilise cron? Une façon d’apprendre cela est de demander cronà nous dire:

1. Créez un script shell dans votre répertoire personnel ( ~/) comme suit (ou avec l'éditeur de votre choix):

$ nano ~/envtst.sh

2. Entrez les informations suivantes dans l'éditeur, après ajustement pour votre système / utilisateur:

#!/bin/sh 
/bin/echo "env report follows for user "$USER >> /home/you/envtst.sh.out 
/usr/bin/env >> /home/you/envtst.sh.out 
/bin/echo "env report for user "$USER" concluded" >> /home/you/envtst.sh.out
/bin/echo " " >> /home/you/envtst.sh.out

3. Enregistrez le fichier, quittez l'éditeur et définissez les autorisations de fichier comme étant exécutables.

$ chmod a+rx ~/envtst.sh

4. Exécutez le script que vous venez de créer et passez en revue le résultat /home/you/envtst.sh.out. Cette sortie montrera votre environnement actuel en tant que $USERvous êtes connecté en tant que:

$ ./envtst.sh $$ cat /home/you/envtst.sh.out

5. Ouvrez votre crontabpour édition:

$ crontab -e -u root

6. Entrez la ligne suivante au bas de votre crontab:

* * * * *  /home/you/envtst.sh >> /home/you/envtst.sh.err 2>&1

REPONSE: Le fichier de sortie /home/you/envtst.sh.outcontiendra une liste des environment"utilisateurs cron root". Une fois que vous savez cela, ajustez votre crontabsaisie en conséquence.

Je ne peux pas spécifier le calendrier dont j'ai besoin dans mon crontabentrée:

L'entrée de programme pour crontabest bien sûr définie dans man crontab, et vous devriez la lire. Cependant, lire man crontabet comprendre l'horaire sont deux choses différentes. Et les essais et erreurs sur une spécification de programme peuvent devenir très fastidieux. Heureusement, il existe une ressource qui peut aider: le gourou crontab. . Entrez les spécifications de votre emploi du temps, qui expliquera l’emploi du temps en anglais clair.

Enfin, et au risque d’être redondant avec l’une des réponses données ici, ne vous laissez pas prendre au piège en pensant que vous êtes limité à une seule crontabentrée car vous avez un travail à programmer. Vous êtes libre d'utiliser autant d' crontabentrées que nécessaire pour obtenir l'horaire dont vous avez besoin.