Pourquoi les scripts crontab ne fonctionnent-ils pas?

Environnement différent

Cron transmet un ensemble minimal de variables d’environnement à vos travaux. Pour voir la différence, ajoutez un travail factice comme celui-ci:

* * * * * env > /tmp/env.output

Attendez que /tmp/env.output soit créé, puis supprimez à nouveau le travail. Maintenant, comparez le contenu de /tmp/env.output avec le résultat de env exécuté dans votre terminal habituel.

Un "gotcha" commun ici est que la variable d'environnement PATH est différente. Peut-être que votre script cron utilise la commande somecommand trouvée dans /opt/someApp/bin , que vous avez ajoutée à PATH dans /etc/environment ? cron ignore PATH à partir de ce fichier. Par conséquent, l'exécution de somecommand à partir de votre script échouera si elle est exécutée avec cron, mais fonctionne lorsqu'elle est exécutée dans un terminal. Il convient de noter que les variables de /etc/environment seront transmises aux tâches cron, mais pas aux variables que cron se définit spécifiquement, telles que PATH .

Pour résoudre ce problème, définissez simplement votre propre variable PATH en haut du script. Ex.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Certains préfèrent simplement utiliser des chemins absolus pour toutes les commandes. Je recommande contre cela. Réfléchissez à ce qui se passe si vous souhaitez exécuter votre script sur un autre système et que, sur ce système, la commande est à la place dans /opt/someAppv2.2/bin . Vous devrez parcourir tout le script en remplaçant /opt/someApp/bin par /opt/someAppv2.2/bin au lieu de simplement effectuer une petite modification sur la première ligne du script.

Vous pouvez également définir la variable PATH dans le fichier crontab, qui s'appliquera à tous les travaux cron. Ex.

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

Mon meilleur truc: si vous oubliez d'ajouter une nouvelle ligne à la fin du fichier crontab . En d'autres termes, le fichier crontab doit se terminer par une ligne vide.

Ci-dessous se trouve la section pertinente des pages de manuel relatives à ce problème ( man crontab puis passez à la fin):

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Le démon Cron n'est pas en cours d'exécution. Je me suis vraiment planté avec ça il y a quelques mois.

Type:

pgrep cron 

Si vous ne voyez aucun numéro, cron ne fonctionne pas. sudo /etc/init.d/cron start peut être utilisé pour démarrer cron.

EDIT: Plutôt que d'appeler des scripts d'initialisation via /etc/init.d, utilisez le service utilitaire, par exemple

sudo service cron start

Les noms de fichiers de script dans cron.d/ , cron.daily/ , cron.hourly/ , etc., ne doivent pas contenir de point ( . ), sinon les parties d'exécution les ignoreront.

Voir les run-parts (8):

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

Ainsi, si vous avez un script cron backup.sh , analyze-logs.pl dans le répertoire cron.daily/ , vous feriez mieux de supprimer les noms d’extension.

Dans de nombreux environnements, cron exécute les commandes à l'aide de sh , tandis que de nombreuses personnes supposent qu'il utilisera bash .

Suggestions de test ou de correction pour une commande en échec:

• Essayez d'exécuter la commande dans sh pour voir si cela fonctionne
• Emballez la commande dans un sous-shell bash pour vous assurer qu'elle sera exécutée dans bash:
  bash -c "mybashcommand"
• Dites à cron d'exécuter toutes les commandes dans bash en plaçant le shell en haut de votre crontab:
  SHELL=/bin/bash
• Si la commande est un script, assurez-vous qu'il contient un shebang:
  #!/bin/bash

J'ai eu quelques problèmes avec les fuseaux horaires. Cron fonctionnait avec le nouveau fuseau horaire d'installation. La solution consistait à redémarrer cron:

sudo service cron restart

Si votre commande crontab contient un symbole % , cron tente de l'interpréter. Donc, si vous utilisiez une commande contenant % (telle qu'une spécification de format pour la commande date), vous devrez l'échapper.

Cela et d’autres bons pièges ici:
lien

Le chemin absolu doit être utilisé pour les scripts:

Par exemple, /bin/grep doit être utilisé à la place de grep :

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Au lieu de:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Ceci est particulièrement délicat, car la même commande fonctionnera lorsqu’elle sera exécutée à partir d’un shell. La raison en est que cron n'a pas la même variable d'environnement PATH que l'utilisateur.

Il est également possible que le mot de passe de l'utilisateur ait expiré. Même le mot de passe de root peut expirer. Vous pouvez tail -f /var/log/cron.log et vous verrez échouer cron avec expiration du mot de passe. Vous pouvez définir le mot de passe pour qu'il n'expire jamais en procédant ainsi: passwd -x -1 <username>

Sur certains systèmes (Debian, Ubuntu), la journalisation de cron n’est pas activée par défaut. Dans /etc/rsyslog.conf ou /etc/rsyslog.d/50-default.conf , la ligne:

# cron.*                          /var/log/cron.log

doit être modifié ( sudo nano /etc/rsyslog.conf ) sans commenter:

cron.*                          /var/log/cron.log

Après cela, vous devez redémarrer rsyslog via

/etc/init.d/rsyslog restart

ou

service rsyslog restart 

Source: Activer la journalisation crontab dans Debian Linux

Sur certains systèmes (Ubuntu), le fichier de journalisation distinct pour cron n’est pas activé par défaut, mais les journaux liés à cron apparaissent dans le fichier syslog. On peut utiliser

cat /var/log/syslog | grep cron

pour afficher les messages liés à cron.

Cron appelle un script qui n'est pas exécutable.

En exécutant chmod +x /path/to/scrip , le script devient exécutable et devrait résoudre ce problème.

Si votre travail cron appelle des applications graphiques, vous devez leur indiquer le type d'affichage à utiliser.

Exemple: lancement de Firefox avec cron.

Votre script doit contenir export DISPLAY=:0 quelque part.

J'ai bien peur que les problèmes d'autorisations ne soient pas rares.

Notez qu'une solution de contournement courante consiste à tout exécuter à l'aide de la crontab de root, qui est parfois une très mauvaise idée. Définir des autorisations appropriées est certainement un problème largement négligé.

Autorisation de table cron non sécurisée

Une table cron est refusée si sa permission n'est pas sécurisée

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

Le problème est résolu avec

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

Le script est sensible à l'emplacement. Cela est lié à l'utilisation constante de chemins absolus dans un script, mais pas tout à fait la même chose. Votre travail cron peut avoir besoin de cd dans un répertoire spécifique avant de s'exécuter, par exemple. une tâche rake sur une application Rails peut avoir besoin d'être à la racine de l'application pour que Rake puisse trouver la tâche correcte, sans oublier la configuration de base de données appropriée, etc.

Donc, une entrée crontab de

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

serait mieux comme

23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production

Ou, pour garder l’entrée crontab plus simple et moins fragile:

23 3 * * * /home/<user>/scripts/session-purge.sh

avec le code suivant dans /home/<user>/scripts/session-purge.sh :

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production

Les spécifications de la crontab qui fonctionnaient dans le passé peuvent tomber en panne lorsqu'elles sont déplacées d'un fichier crontab à un autre. La raison en est parfois que vous avez déplacé les spécifications d'un fichier crontab système vers un fichier crontab utilisateur ou vice-versa.

Le format de spécification du travail cron diffère entre les fichiers crontab des utilisateurs (/ var / spool / cron / nomutilisateur ou / var / spool / cron / crontabs / nomutilisateur) et les fichiers crontabs système ( /etc/crontab et les fichiers dans /etc/cron.d ).

Les tableaux croisés du système ont un champ supplémentaire "utilisateur" juste avant la commande à exécuter.

Cela provoquera des erreurs indiquant des choses comme george; command not found lorsque vous déplacez une commande hors de /etc/crontab ou un fichier de /etc/cron.d dans le fichier crontab d'un utilisateur.

Inversement, cron générera des erreurs du type /usr/bin/restartxyz is not a valid username ou similaire lorsque l'inverse se produit.

Le script cron appelle une commande avec l'option --verbose

Un script cron m'a échoué parce que j'étais en pilote automatique lors de la saisie du script et que j'ai inclus l'option --verbose:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

Le script a fonctionné correctement lors de l'exécution à partir du shell, mais a échoué lors de l'exécution à partir de crontab car la sortie détaillée passait à stdout lors de l'exécution à partir du shell, mais nulle part ailleurs à partir de crontab. Solution facile pour supprimer le 'v':

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

La raison la plus fréquente pour laquelle j'ai vu le programme cron échouer était mal programmée. Il faut de la pratique pour spécifier un travail planifié pour 23h15 sous la forme 30 23 * * * au lieu de * * 11 15 * ou 11 15 * * * . Le jour de la semaine pour les emplois après minuit est également confus. M-F est 2-6 après minuit et non pas 1-5 . Les dates spécifiques sont généralement un problème car nous les utilisons rarement. * * 3 1 * n'est pas le 3 mars.

Si vous travaillez avec différentes plates-formes en utilisant des options non prises en charge telles que 2/3 , les spécifications temporelles peuvent également entraîner des échecs. C'est une option très utile mais non disponible universellement. J'ai également rencontré des problèmes tels que 1-5 ou 1,3,5 .

L’utilisation de chemins non qualifiés a également causé des problèmes. Le chemin par défaut est généralement /bin:/usr/bin , de sorte que seules les commandes standard seront exécutées. Ces répertoires n'ont généralement pas la commande souhaitée. Cela affecte également les scripts utilisant des commandes non standard. D'autres variables d'environnement peuvent également être manquantes.

Le brouillage total d’une crontab existante m’a causé des problèmes. Je charge maintenant à partir d'une copie de fichier. Cela peut être récupéré à partir de la crontab existante en utilisant crontab -l si elle est bouchée. Je garde la copie de crontab dans ~ / bin. Il est commenté tout au long et se termine par la ligne # EOF . Ceci est rechargé quotidiennement à partir d'une entrée de crontab telle que:

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

La commande de rechargement ci-dessus repose sur une crontab exécutable avec un chemin bang exécutant crontab. Certains systèmes requièrent l'exécution de la commande crontab dans la commande et la spécification du fichier. Si le répertoire est partagé sur le réseau, j'utilise souvent crontab.$(hostname) comme nom du fichier. Cela corrigera éventuellement les cas où la mauvaise crontab est chargée sur le mauvais serveur.

L'utilisation du fichier fournit une sauvegarde de ce que devrait être la crontab, et permet aux modifications temporaires (la seule fois où j'utilise crontab -e ) d'être automatiquement sauvegardées. Des en-têtes sont disponibles pour vous aider à définir correctement les paramètres de planification. Je les ai ajoutés lorsque des utilisateurs inexpérimentés éditaient une crontab.

Rarement, j'ai rencontré des commandes nécessitant la saisie de l'utilisateur. Celles-ci échouent sous crontab, bien que certaines fonctionnent avec la redirection d’entrée.

Si vous accédez à un compte via des clés SSH, il est possible de vous connecter au compte, mais vous ne remarquerez pas que le mot de passe du compte est verrouillé (par exemple, en cas d'expiration ou de tentative de mot de passe invalide)

Si le système utilise PAM et que le compte est verrouillé, son travail cronjob peut être interrompu. (J'ai testé cela sur Solaris, mais pas sur Ubuntu)

Vous pouvez trouver des messages comme celui-ci dans / var / adm / messages:

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Il vous suffit de lancer:

# passwd -u <USERNAME>

en tant que root pour déverrouiller le compte et la crontab devrait fonctionner à nouveau.

Si vous avez une commande comme celle-ci:

* * * * * /path/to/script >> /tmp/output

et cela ne fonctionne pas et vous ne voyez aucune sortie, cela ne signifie pas nécessairement que cron ne fonctionne pas. Le script pourrait être cassé et la sortie irait à stderr qui ne serait pas transmise à / tmp / output. Vérifiez que ce n'est pas le cas, en capturant également cette sortie:

* * * * * /path/to/script >> /tmp/output 2>&1

pour voir si cela vous aide à résoudre votre problème.

Dans mon cas, cron et crontab avaient des propriétaires différents.

NE FONCTIONNE PAS J'avais ceci:

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

En gros, je devais exécuter cron-config et répondre correctement aux questions. À un moment donné, il m'a été demandé de saisir mon mot de passe d'utilisateur Win7 pour mon compte "Utilisateur". D'après ce que j'ai lu, il semble que ce soit un problème de sécurité potentiel, mais je suis le seul administrateur d'un seul réseau domestique et j'ai donc décidé que tout allait bien.

Voici la séquence de commandes qui m'a permis de continuer:

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $

J'écrivais un script d'installation qui crée un autre script pour purger les anciennes données de transaction d'une base de données. Dans le cadre de cette tâche, elle devait configurer le travail quotidien cron pour s'exécuter à une heure arbitraire, lorsque la charge de la base de données était faible.

J'ai créé un fichier mycronjob avec le planning cron, le nom d'utilisateur & la commande et l'a copiée dans le répertoire /etc/cron.d . Mes deux pièges:

1. Le fichier mycronjob devait appartenir à root pour pouvoir être exécuté
2. Je devais définir les autorisations du fichier sur 644 - 664 ne s'exécuteraient pas.

Un problème de permission apparaîtra dans /var/log/syslog comme quelque chose de similaire à:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

La première ligne fait référence à /etc/crontab fichier et la dernière à un fichier que j'ai placé sous /etc/cront.d .

=== Alerte Docker ===

Si vous utilisez le menu fixe,

Je pense qu'il convient d'ajouter que je ne pouvais pas faire fonctionner cron en tâche de fond.

Pour exécuter un travail cron à l'intérieur du conteneur, j'ai utilisé supervisor et exécuté cron -f , conjointement avec l'autre processus.

Modifier: autre problème - je n’arrivais pas à le faire fonctionner lors de l’exécution du conteneur avec la mise en réseau HOST. Voir ce numéro ici aussi: link

La ligne écrite de manière à ce que crontab ne comprenne pas. Il doit être correctement écrit. Voici CrontabHowTo .

Le démon Cron est peut-être en cours d'exécution, mais ne fonctionne pas réellement. Essayez de redémarrer cron:

sudo /etc/init.d/cron restart

Écriture dans cron via "crontab -e" avec l'argument nom d'utilisateur dans une ligne. J'ai vu des exemples d'utilisateurs (ou d'administrateurs système) écrivant leurs scripts shell sans comprendre pourquoi ils ne s'automatisaient pas. L'argument "utilisateur" existe dans / etc / crontab, mais pas dans les fichiers définis par l'utilisateur. Ainsi, par exemple, votre dossier personnel serait quelque chose comme:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

alors que / etc / crontab serait:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Alors, pourquoi voudriez-vous faire ce dernier? En fonction de la manière dont vous souhaitez définir vos autorisations, cela peut devenir très compliqué. J'ai écrit des scripts pour automatiser des tâches destinées à des utilisateurs qui ne comprennent pas les subtilités ou qui ne veulent pas s'embarrasser de tâches fastidieuses. En définissant les autorisations sur --x------ , je peux rendre le script exécutable sans qu’ils puissent le lire (et peut-être le modifier accidentellement). Cependant, je souhaiterais peut-être exécuter cette commande avec plusieurs autres à partir d'un fichier (ce qui facilitera sa maintenance), mais assurez-vous que le fichier est correctement attribué au propriétaire. Cela (du moins dans Ubuntu 10.10) interrompt à la fois l’impossibilité de lire et d’exécuter le fichier, ainsi que le problème susmentionné de placer des périodes dans / etc / crontab (qui, curieusement, ne cause aucune erreur lors du passage à crontab -e ).

À titre d'exemple, j'ai vu des instances de sudo crontab -e utilisées pour exécuter un script avec des autorisations root, avec un chown username file_output correspondant dans le script shell. Sloppy, mais ça marche. À mon humble avis, l’option la plus gracieuse consiste à la placer dans /etc/crontab avec le nom d’utilisateur déclaré et les autorisations appropriées, de sorte que file_output se rende au bon endroit et au bon propriétaire.

Pour reprendre ce que Aaron Peart a mentionné à propos du mode commenté, des scripts qui ne sont pas en mode commenté s’initialisent mais ne se terminent pas si le comportement par défaut d’une commande incluse consiste à afficher une ou plusieurs lignes à l’écran une fois le processus lancé. Par exemple, j’ai écrit pour notre intranet un script de sauvegarde qui utilisait curl, un utilitaire qui télécharge ou télécharge des fichiers sur des serveurs distants. C’est très pratique si vous ne pouvez accéder auxdits fichiers distants que via HTTP. L'utilisation de 'curl link ' provoquait le blocage d'un script que j'avais écrit et qui ne finissait jamais car il créait une nouvelle ligne suivie d'une ligne de progression. Je devais utiliser le drapeau silencieux (-s) pour lui dire de ne donner aucune information et écrire dans mon propre code pour le gérer si le téléchargement du fichier échouait.

Bien que vous puissiez définir des variables d'environnement dans votre crontable, vous n'êtes pas dans un script shell. Donc, des constructions comme celle-ci ne fonctionneront pas:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Cela est dû au fait que les variables ne sont pas interprétées dans la table de contrôle: toutes les valeurs sont prises littéralement. Et c'est pareil si vous omettez les crochets. Ainsi, vos commandes ne seront pas exécutées et vos fichiers journaux ne seront pas écrits ...

Au lieu de cela, vous devez définir toutes vos variables d'environnement directement:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Lorsqu'une tâche est exécutée dans cron, stdin est fermé. Les programmes qui agissent différemment selon que stdin est disponible ou non se comporteront différemment entre la session shell et cron.

Un exemple est le programme goaccess pour l'analyse des fichiers journaux du serveur Web. Cela ne marche PAS dans cron:

goaccess -a -f /var/log/nginx/access.log > output.html

et goaccess affiche la page d'aide au lieu de créer le rapport. Dans le shell, cela peut être reproduit avec

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

Le correctif pour goaccess consiste à faire en sorte que le journal soit lu depuis stdin au lieu de le lire dans le fichier. La solution consiste donc à remplacer l'entrée de la crontab par

cat /var/log/nginx/access.log | goaccess -a > output.html

Sur mes serveurs RHEL7, les travaux root cron s'exécutent, mais pas les travaux utilisateur. J'ai trouvé que sans un répertoire personnel, les travaux ne s'exécuteraient pas (mais vous verrez de bonnes erreurs dans / var / log / cron). Lorsque j'ai créé le répertoire personnel, le problème a été résolu.

Si vous avez modifié votre fichier crontab à l'aide d'un éditeur Windows (via samba ou quelque chose de ce genre) et qu'il a remplacé les nouvelles lignes par \ n \ r ou simplement \ r, cron ne s'exécutera pas.

De même, si vous utilisez /etc/cron.d/* et que l'un de ces fichiers contient un \ r, cron se déplacera dans les fichiers et s'arrêtera lorsqu'il détecte un fichier endommagé. Vous ne savez pas si c'est le problème?

Utiliser:

od -c /etc/cron.d/* | grep \r