Pourquoi les scripts crontab ne fonctionnent pas?
Souvent, les scripts crontab ne sont pas exécutés comme prévu ou comme prévu. Il y a de nombreuses raisons à cela:
- mauvaise notation crontab
- problème d'autorisations
- variables d'environnement
Ce wiki de communauté vise à regrouper les principales raisons pour lesquelles les scripts crontab 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 des problèmes spécifiques à Cron, par exemple 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 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 standard.
Un "gotcha" commun ici est que la variable d'environnement PATH est différente. Peut-être que votre script cron utilise la commande somecommand qui se trouve 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 à la variable définie par cron, telle que PATH.
Pour contourner ce problème, définissez simplement votre propre variable PATH 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 plutôt à /opt/someAppv2.2/bin. Vous devez 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. 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 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.
Vous trouverez ci-dessous 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’invoquer des scripts d’initialisation via /etc/init.d, utilisez l’utilitaire de service, par exemple
Sudo service cron start
Les noms de fichier 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 des commandes à l'aide de shname__, alors que de nombreuses personnes supposent qu'il utilisera bashname__.
Suggestions pour tester ou résoudre ce problème pour une commande qui échoue:
Essayez d’exécuter la commande dans
shpour voir si elle 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/bashSi 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/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 de Shell. La raison en est que cron n'a pas la même variable d'environnement PATH que l'utilisateur.
Si votre commande crontab contient un symbole %, cron tente de l'interpréter. Donc, si vous utilisiez une commande contenant un % (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/scrip, le 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.log et vous verrez l'échec de cron avec expiration du mot de passe. Vous pouvez définir 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 tâche cron appelle des applications à interface graphique, vous devez leur dire quel type d'affichage ils doivent utiliser.
Exemple: lancement de Firefox avec cron.
Votre script doit contenir export DISPLAY=:0 quelque 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 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 devoir être à la racine de l'application pour que Rake puisse trouver la tâche correcte, sans parler de 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 se briser lorsqu’elles sont déplacées d’un fichier crontab à un autre. Parfois, la raison en est que vous avez déplacé les spécifications d'un fichier crontab système vers un fichier crontab utilisateur ou inversement.
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 contenus dans /etc/cron.d).
Les crontabs du système ont un champ supplémentaire "utilisateur" juste avant la commande à exécuter.
Cela provoquera des erreurs indiquant des éléments tels que george; command not found lorsque vous déplacerez 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 telles que /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é 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 de Shell, mais a échoué lors de l'exécution à partir de crontab car la sortie détaillée passe à stdout lorsqu'elle est exécutée à partir de 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é à 23h15 sous la forme 30 23 * * * au lieu de * * 11 15 * ou 11 15 * * *. Le jour de la semaine pour les travaux 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 dans les spécifications de temps, vous risquez également de rencontrer des problèmes. C'est une option très utile mais non disponible universellement. J'ai également rencontré des problèmes avec des listes telles 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.
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 -l si elle est bouchée. Je garde la copie de crontab dans ~/bin. Il est commenté 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/crontabLa 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) 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 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 ne remarque pas que le mot de passe du compte est verrouillé (par exemple, en cas d'expiration ou de tentatives de mot de passe non valides).
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 avis] 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 avis] pam_unix_account: cron tente de valider le compte verrouillé de l'utilisateur local. 24 oct. 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account : cron essayant de valider le compte verrouillé myuser à partir 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 aller à stderr qui ne sera pas passé à/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.
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 la tâche, il devait configurer le travail quotidien cron à exécuter à une heure arbitraire, lorsque le chargement de la base de données était faible.
J'ai créé un fichier mycronjob avec la planification cron, le nom d'utilisateur et la commande, puis je l'ai copié dans le répertoire /etc/cron.d. Mes deux pièges:
- Le fichier
mycronjobdevait appartenir à root pour être exécuté - Je devais définir les autorisations du fichier sur 644 - 664 ne fonctionneraient 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 au fichier /etc/crontab et la dernière à un fichier que j'ai placé sous /etc/cront.d.
=== 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é supervisor et exécuté cron -f, conjointement avec 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 de l'hôte. Voir ce numéro ici aussi: https://github.com/phusion/baseimage-docker/issues/144
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
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}
En se fondant sur ce que Aaron Peart a mentionné à propos du mode commenté, les 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.
En 16.04, si vous avez cette erreur dans syslog
(CRON) error (can't fork)
essayer:
systemctl status cron.service
Au résultat:
Tasks: num_task (limit: 512)
Si num_task est proche de la limite d'utilisation:
systemctl set-property cron.service TasksMax=new_max
Remplacez new_max par une valeur appropriée.
La ligne écrite d'une manière que crontab ne comprend pas. Il doit être correctement écrit. Voici CrontabHowTo .
Sur mes serveurs RHEL7, les tâches root root sont exécutées, mais pas les tâches 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.
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 qu’ils puissent le lire (et même 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) rompt à 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 (qui, curieusement, ne cause aucune erreur lors du passage à crontab -e ).
A 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. IMHO, l'option la plus gracieuse est de le mettre dans /etc/crontab avec le nom d'utilisateur déclaré et les autorisations appropriées, afin que file_output se rende au bon endroit et au bon propriétaire.
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 analyser les 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 la coque, ceci peut être reproduit avec
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null
Le correctif pour goaccess consiste à ce qu'il lise le journal à partir de 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
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 ~ $
Si vous avez modifié votre fichier crontab à l'aide d'un éditeur Windows (via samba ou quelque chose de ce type) 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
Les fichiers .bashrc par défaut sur UBuntu 16.04 (et de nombreuses autres versions) ont un mécanisme intégré permettant de ne rien faire s’ils ne sont pas un shell interactif
Cela peut empêcher la création correcte du fichier dans un script exécuté par cron! Pour éviter cela, commentez les lignes suivantes du haut de votre fichier .bashrc:
Ubuntu 16.04
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
Ubuntu 12.04 et quelques autres versions
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
Tant que ceux-ci sont conservés si cron exécute un script qui code votre fichier .bashrc, vous n'obtiendrez en réalité aucune des variables d'environnement auxquelles vous êtes habitué dans votre terminal!
Un autre Gotcha:
Lorsque vous tapez crontab -e et que vous enregistrez dans l'éditeur, cela n'aura aucun effet. Vous devez quitter l'éditeur pour qu'il soit ajouté ou mis à jour en fonction de vos modifications (par exemple, utilisez :x dans Vim).
(crontab -e exécute effectivement "edit cron file; update from cron file" afin qu'il bloque l'éditeur jusqu'à ce que vous le fermiez.)
J'ai eu un problème avec un script qui appelait grep avec une expression régulière. Certaines expressions rationnelles fonctionnaient lorsque le script était appelé depuis crontab, tandis que d'autres ne fonctionnaient pas, par exemple. [[: print:]] n'a pas fonctionné. Il s'avère que la variable d'environnement LANG a un impact sur les jeux de caractères tels que [a-z] ou [[: print:]]. Lorsque j'ai collé ma variable d'environnement LANG dans la partie supérieure de ma crontab, c'est-à-dire "LANG = en_GB.UTF-8", les expressions rationnelles grep ont toutes bien fonctionné lorsque le script a été appelé à partir de la crontab. HTH.
Journalisation des autorisations
Une crontab très simple, ne s'exécutera pas car /var/log/ n'est pas accessible en écriture pour le compte luser!
* * * * * /usr/local/bin/teamviewer_check >> /var/log/teamviewer.log 2>&1
SOLUTION: créez le fichier en tant que root et chmod à 777
Merci à la suggestion précédente d'activer la connexion cron dans /etc/rsyslog.d/50-default.conf, conduit à l'entrée syslog (No MTA installed, discarding output), puis grâce à "((CRON) info (Aucun MTA installé, suppression de la sortie)" dans le syslog installer postfix en local mode, tail/var/mail/luser, /bin/sh: 1: cannot create /var/log/teamviewer.log: Permission denied
Une autre mise en garde:
Essayez de ne pas mettre vos scripts cron dans le répertoire personnel d'un utilisateur.
J'ai juste eu un problème où tout semblait aller bien, mais juste après un moment - probablement quelques heures après ma déconnexion, les tâches cron cessent de fonctionner et ces messages apparaissent dans le journal:
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
Mon répertoire personnel, du moins autant que je sache, n'est pas crypté. Néanmoins, le fait de déplacer ces scripts hors du répertoire home a résolu le problème.
Ma crontab ne fonctionnait que lorsque je me suis connecté en tant qu'utilisateur.
J'ai trouvé la solution suggérée ici sous Unix et Linux SE
Le problème était que les scripts se trouvaient dans mon répertoire personnel crypté. Donc, il sera démonté et indisponible lorsque je me suis connecté. Vous pouvez utiliser la commande mountpour voir si votre répertoire de base est monté pour le chiffrement.
J'ai résolu le problème en mettant mes scripts dans le dossier /usr/local/bin.
Après des heures, j'ai découvert le problème où, je modifiais le script Shell à partir de Windows ( notepad ++ ), où le fichier se trouvait à l'origine dans un serveur Linux et I 'ai raté le caractère de la nouvelle ligne.
Depuis que j'utilisais Notepad ++ pour éditer le fichier, je devais faire la conversion EOL en Unix pour obtenir le nouveau caractère de ligne, et cela a fonctionné parfaitement.
J'espère que ça aide!
Si crontab mentionne quelque chose comme run-parts /etc/cron.daily, alors run-parts peut-être refuser d'exécuter votre script. Dans mon cas, le script dans cron.daily n'a pas commencé par #!/Bin/sh.
J'ai découvert cela en plaçant mon script dans un répertoire et en exécutant run-parts sur ce répertoire.
C'est ce qui m'est arrivé récemment: j'avais deux lignes qui ont modifié PATH, comme ceci:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/ernesto/bin
Ensuite, plus tard dans le fichier:
PATH=$PATH:/some/other/path
comme on le ferait généralement dans un contexte interprété par Shell. Cependant, $ PATH ne semble pas avoir été étendu, ce qui a entraîné l'échec de tous mes travaux. La solution consiste à tout mettre sur une seule ligne.
Modifier:
Comme je ne voulais pas attendre la prochaine itération normale d'anacron pour vérifier que mes tâches fonctionnaient correctement, j'ai lancé:
anacron -fnd "jobname"
Où "jobname" correspond à l'identifiant de travail spécifié dans anacrontab. Cela oblige les tâches à être exécutées par le même processus anacron, séquentiellement et sans délai.
Les tâches cron ne s'exécutent pas si le mot de passe de votre utilisateur a expiré.
Une indication de cela est si votre journal cron (généralement /var/log/syslog sur Ubuntu, je crois) contient des messages tels que "Le jeton d'authentification n'est plus valide, un nouveau requis".
Vous pouvez vérifier ce problème en exécutant Sudo chage -l the_username.
Voici un exemple de mot de passe expiré:
$ Sudo chage -l root
Last password change : password must be changed
Password expires : password must be changed
Password inactive : password must be changed
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 14600
Number of days of warning before password expires : 14
La solution est de changer le mot de passe. Par exemple:
Sudo -u root passwd
Suivez ensuite les instructions en spécifiant un nouveau mot de passe, comme demandé.
Merci à https://serverfault.com/questions/449651/why-is-my-crontab-not-working-and-how-can-i-troubleshoot-it#comment966708_544905 pour m'avoir désigné la bonne direction ici. Dans mon cas, tout comme pour ce commentateur, il s'agissait de l'utilisateur racine d'une boîte DigitalOcean.
Vous avez utilisé:
* * * * * DISPLAY=:0 /path/to/your/app
mais cela a échoué car votre répertoire ~/.dbus n'appartient pas à vous mais à la racine. Vérifie ça:
ls -l ~/.dbus
Une fois, je travaillais sur un serveur partagé avec beaucoup de restrictions .
Toutes les réponses ici (PATH, Shell, bash -c, ...) n’ont pas pu faire fonctionner mon script dans la crontab.
Cela fonctionnait parfaitement lorsque je plaçais la commande dans un peu fichier script avec le PATH, Shell et Shebang plutôt que dans la crontab elle-même. J'ai dû changer les autorisations à 700.
Parfois, cron fonctionne très bien, mais le script ou la commande que vous voulez exécuter échoue de manière silencieuse, ce qui vous oblige à aboyer le mauvais arbre.
Dans de tels cas, il est utile de placer la cible dans un autre script court, qui génère du code de débogage visible (y compris la sortie de date) et d’utiliser la redirection pour garantir que je reçoive des preuves à inspecter. Si la cible est un script, entourer un sh -x peut aider davantage.
L’entrée crontab (toujours éditer avec crontab -e) pourrait ressembler à ceci:
00 14 * * * (sh -x /tmp/my_wrapper_script) >> /tmp/debug.log 2>&1
Inspectez /tmp/debug.log et son horodatage. Si elle est vide, inexistante ou si l'horodatage survient peu de temps après 14h00 (dans cet exemple), vous pouvez avoir un problème de cron, sinon vous devez déboguer l'action cible réelle et cron fonctionne parfaitement!
J'ai eu quelques problèmes avec l'utilisation de Sudo dans un cron.
En gros, je voulais exécuter une commande en tant qu’utilisateur spécifique et j’ai tout d’abord testé, à la ligne de commande, su, qui a renvoyé l’erreur This account is not available. En utilisant Sudo, la commande s'est exécutée sans erreur.
Toutefois, lors de l'exécution de cron, la commande Sudo a renvoyé l'erreur suivante: Sudo: sorry, you must have a tty to run Sudo.
J'ai découvert par la suite que l'utilisation de runuser et la spécification d'un shell pour l'exécution de la commande fonctionnaient.
Si vous exécutez des scripts dans les répertoires /etc/cron.*, assurez-vous que vos scripts:
- sont exécutables,
- correspond à l'espace de noms du script cron Ubuntu/Debian
(^[a-zA-Z0-9_-]+$).
Ainsi, par exemple, si vous avez un script avec une extension (telle que .sh) ne fonctionnera pas.
Pour imprimer les noms des scripts à exécuter sur une base horaire, essayez:
Sudo run-parts --report --test /etc/cron.hourly