Pourquoi les scripts crontab ne fonctionnent pas?

Souvent, les crontabscripts ne sont pas exécutés comme prévu ou comme prévu. Il y a de nombreuses raisons à cela:

1. mauvaise notation crontab
2. problème d'autorisations
3. Variables d'environnement

Ce wiki de communauté vise à regrouper les principales raisons pour lesquelles les crontabscripts ne sont pas exécutés comme prévu. Écris chaque raison dans une réponse distincte.

Veuillez inclure une raison par réponse - les détails sur la raison pour laquelle elle n'est pas exécutée - et corrigez le (s) problème (s) pour cette raison.

N'écrivez que les problèmes spécifiques à cron, par exemple les commandes qui s'exécutent comme prévu à partir du shell mais s'exécutent de manière erronée avec cron.

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 /tmp/env.outputd’être créé, puis supprimez à nouveau le travail. Maintenant, comparez le contenu de /tmp/env.outputavec la sortie de envrun dans votre terminal habituel.

Un "gotcha" commun ici est que la PATHvariable d'environnement est différente. Peut-être votre script cron utilise la commande somecommandtrouvée dans /opt/someApp/bin, que vous avez ajouté à PATHen /etc/environment? cron ignore PATHce fichier, donc l'exécution somecommandde 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/environmentseront transmises aux tâches cron, mais pas les variables que cron se définit spécifiquement, telles que PATH.

Pour contourner ce problème, définissez simplement votre propre PATHvariable en haut du script. Par exemple

#!/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 par contre. Considérez 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 /opt/someAppv2.2/binplace. Vous devrez parcourir tout le script en remplaçant /opt/someApp/binpar /opt/someAppv2.2/binau lieu de simplement faire 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. Par exemple

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

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

Mon haut le casse-tête: Si vous oubliez d'ajouter une nouvelle ligne à la fin du crontabfichier. En d'autres termes, le fichier crontab doit se terminer par une ligne vide.

Vous trouverez ci-dessous la section appropriée dans les pages de manuel de ce problème ( man crontabpassez à 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 startpeut être utilisé pour démarrer cron.

EDIT: Plutôt que d’invoquer des scripts d’initialisation via /etc/init.d, utilisez l’utilitaire de service, par exemple

sudo service cron start

EDIT: Vous pouvez aussi utiliser systemctl dans Linux moderne, par exemple

sudo systemctl start cron

Le script noms de fichiers cron.d/, cron.daily/, cron.hourly/, etc., ne doivent pas contenir de point ( .), sinon run-parts seront les sauter.

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_-]+$).

Donc, si vous avez un script cron backup.sh, analyze-logs.pldans le cron.daily/répertoire, vous feriez mieux de supprimer les noms d'extension.

Dans de nombreux environnements, cron exécute les commandes en utilisant sh, alors que de nombreuses personnes supposent qu'il l'utilisera bash.

Suggestions pour tester ou résoudre ce problème pour une commande qui échoue:

• Essayez d’exécuter la commande shpour voir si cela fonctionne:

  sh -c "mycommand"
  

• Emballez la commande dans un sous-shell bash pour vous assurer qu’elle est 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 était de redémarrer cron:

sudo service cron restart

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

Par exemple, /bin/grepdevrait ê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 cronn'a pas la même PATHvariable d'environnement que l'utilisateur.

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

Cela et d’autres bons pièges ici:
http://www.pantz.org/software/cron/croninfo.html

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

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

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.loget vous verrez que cron échoue avec le mot de passe expiré. Vous pouvez configurer le mot de passe pour qu'il n'expire jamais en procédant comme suit: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

devrait être édité ( sudo nano /etc/rsyslog.conf) non commenté à:

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

Dans 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 -i

pour afficher les messages liés à cron.

Si votre cronjob appelle des applications GUI, vous devez leur dire quel type d'affichage ils doivent utiliser.

Exemple: lancement de Firefox avec cron.

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

Les problèmes d'autorisations sont assez fréquents, j'en ai bien peur.

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 définitivement un problème largement négligé.

Permission non sécurisée sur la table cron

Une table cron est rejetée si son autorisation 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. Ceci est lié à l'utilisation constante de chemins absolus dans un script, mais pas tout à fait la même chose. Votre tâche cron cddevra peut-être accéder à un répertoire spécifique avant d'être exécutée. Par exemple, une tâche rake sur une application Rails peut avoir besoin de se trouver à la racine de l'application pour que Rake trouve la tâche correcte, sans mentionner 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 / actuel
/ usr / bin / rake db: session_purge RAILS_ENV = production

Les spécifications de Crontab qui ont fonctionné dans le passé peuvent casser lorsqu’elles sont déplacées d’un fichier crontab à un autre. Parfois, la raison est que vous avez déplacé la spécification d'un fichier crontab système vers un fichier crontab utilisateur ou inversement.

Le format de spécification de 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/crontabet les fichiers qu'ils contiennent /etc/cron.d).

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

Cela provoquera des erreurs george; command not foundlors de /etc/crontabdéclarations telles que le déplacement d'une commande ou d'un fichier dans /etc/cron.dle fichier crontab d'un utilisateur.

Inversement, cron générera des erreurs similaires /usr/bin/restartxyz is not a valid usernameou similaires lorsque l'inverse se produit.

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

Un script cron m'a échoué car j'étais en pilote automatique lors de la saisie du script et 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 passe à 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 au 15 23 * * *lieu de * * 11 15 *ou 11 15 * * *. Le jour de la semaine pour les travaux après minuit est également confus. MF est 2-6après minuit, non 1-5. Les dates spécifiques sont généralement un problème car nous les utilisons rarement, * * 3 1 *pas le 3 mars. Si vous n’êtes pas sûr, consultez vos plannings cron en ligne à l’ adresse https://crontab.guru/ .

Si vous travaillez avec différentes plates-formes en utilisant des options non prises en charge, telles que les 2/3spécifications temporelles, peut également entraîner des défaillances. C'est une option très utile mais non disponible universellement. J'ai également rencontré des problèmes avec des listes comme 1-5ou 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/binutilisé afin que seules les commandes standard soient 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.

Clobber entièrement 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 -lsi 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 crontab comme:

#! / usr / bin / crontab
# Recharger cette crontab
#
54 12 * * * $ {HOME} / bin / crontab

La commande de rechargement ci-dessus repose sur une crontab exécutable avec un chemin de bang exécutant crontab. Certains systèmes nécessitent la crontab en cours d'exécution dans la commande et la spécification du fichier. Si le répertoire est partagé sur le réseau, j'utilise souvent crontab.$(hostname)le 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 éditions temporaires (la seule fois que j'utilise crontab -e) d'être annulées automatiquement. 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 l'intervention 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é (en raison d'une tentative de mot de passe périmée ou non valide, par exemple).

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:

24 oct 07:51:00 mybox cron [29024]: [ID 731128 authentification] pam_unix_account: cron essayant de valider le compte verrouillé myuser de l'hôte local
24 oct 07:52:00 mybox cron [29063]: [ID 731128 authentification] pam_unix_account: cron essayant de valider le compte verrouillé myuser de l'hôte local
24 oct 07:53:00 mybox cron [29098]: [ID 731128 authentification] pam_unix_account: cron essayant de valider le compte verrouillé myuser de l'hôte local
24 oct 07:54:00 crbox mybox [29527]: [ID 731128 auth.notice] pam_unix_account: cron tente de valider le compte verrouillé myuser de l'hôte local

Tout ce que vous devez faire est de courir:

# passwd -u <NOM D'UTILISATEUR>

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 passée à / 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.

=== Alerte Docker ===

Si vous utilisez docker,

Je pense qu'il convient d'ajouter que je n'ai pas réussi à faire fonctionner cron en tâche de fond.

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

Edit: Un autre problème - Je n'ai pas non plus réussi à le faire fonctionner lors de l'exécution du conteneur avec la mise en réseau HOST. Voir ce numéro ici aussi: https://github.com/phusion/baseimage-docker/issues/144

J'écrivais un script shell 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, il devait configurer le crontravail quotidien pour s’exécuter à une heure arbitraire, lorsque la charge de la base de données était faible.

J'ai créé un fichier mycronjobavec le programme cron, le nom d'utilisateur et la commande et l' ai copié dans le /etc/cron.drépertoire. Mes deux pièges:

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

Un problème d'autorisation apparaîtra /var/log/syslogcomme 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/crontabfichier et la dernière à un fichier que j'ai placé sous /etc/cront.d.

La ligne écrite d'une manière que crontab ne comprend pas. Il doit être correctement écrit. Voici CrontabHowTo .

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

sudo /etc/init.d/cron restart

Ecrire 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 le 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 que ceux-ci puissent le lire (et peut-être le modifier accidentellement). Cependant, je souhaiterais peut-être exécuter cette commande avec plusieurs autres d'un fichier (ce qui facilitera sa maintenance), mais assurez-vous que le bon propriétaire du fichier est attribué à la sortie du fichier. 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 mentionné précédemment avec la mise de périodes dans / etc / crontab (ce qui, assez curieusement, ne cause aucune erreur lors du passage crontab -e). .

Par exemple, j'ai vu des exemples de personnes ayant l' sudo crontab -ehabitude d'exécuter un script avec des autorisations root, avec une correspondance chown username file_outputdans le script shell. Sloppy, mais ça marche. IMHO, l'option la plus gracieuse est de le mettre /etc/crontabavec le nom d'utilisateur déclaré et les autorisations appropriées, pour file_outputaller au bon endroit et au bon propriétaire.

En se basant sur 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 http://something.com/somefile.xls ' 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 celles-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}

En effet, les variables ne sont pas interprétées dans la crontable: 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 in cron.

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

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

et goaccessaffiche la page d'aide au lieu de créer le rapport. Dans la coque, ceci peut être reproduit avec

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

Le correctif goaccessest de le faire lire le journal depuis stdin au lieu de le lire dans le fichier. La solution consiste donc à modifier l’entrée crontab en

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

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

Je ne travaillais 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 sur un seul réseau domestique et j'ai donc décidé que tout allait bien.

Voici la séquence de commande 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 [email protected].
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 ~ $

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 plus, 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?

Utilisation:

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