web-dev-qa-db-fra.com

CronTab ne fonctionne pas

J'ai installé cronjob pour l'utilisateur root dans l'environnement Ubuntu comme suit en tapant crontab -e

  34 11 * * * sh /srv/www/live/CronJobs/daily.sh
  0 08 * * 2 sh /srv/www/live/CronJobs/weekly.sh
  0 08 1 * * sh /srv/www/live/CronJobs/monthly.sh

Mais le cronjon ne court pas. J'ai essayé de vérifier si le travail cron est en cours d'exécution en utilisant 

pgrep cron

et cela donne l'ID de processus 3033. Le script shell appelle un fichier python et est utilisé pour envoyer un courrier électronique. L'exécution du fichier python est ok. Il n'y a pas d'erreur mais le cron ne fonctionne pas. Le fichier daily.sh contient le code suivant.

python /srv/www/live/CronJobs/daily.py
python /srv/www/live/CronJobs/notification_email.py
python /srv/www/live/CronJobs/log_kpi.py
linuxubuntu-12.04crontab
24
Roshan Bhandari

Finalement j'ai trouvé la solution. Voici la solution: -

  1. N'utilisez jamais le chemin relatif dans les scripts python pour être exécuté via crontab .

    import os
import sys
import time, datetime

CLASS_PATH = '/srv/www/live/mainapp/classes'
SETTINGS_PATH = '/srv/www/live/foodtrade'
sys.path.insert(0, CLASS_PATH)
sys.path.insert(1,SETTINGS_PATH)

import other_py_files

  2. Ne supprimez jamais le code crontab, utilisez plutôt mailserver et vérifiez le courrier pour l'utilisateur. Cela donne une idée plus claire de ce qui se passe.

6
Roshan Bhandari

Une autre raison pour laquelle crontab va échouer: Traitement spécial du caractère %.

À partir du fichier man :

The entire command portion of the line, up to a newline or a
"%" character, will be executed by /bin/sh or by the Shell specified
in the Shell variable of the cronfile.  A "%" character in the
command, unless escaped with a backslash (\), will be changed into
newline characters, and all data after the first % will be sent to
the command as standard input.

Dans mon cas particulier, j’utilisais date --date="7 days ago" "+%Y-%m-%d" pour générer des paramètres dans mon script, et cela échouait silencieusement. J'ai finalement découvert ce qui se passait lorsque j'ai vérifié syslog et que ma commande a été tronquée au symbole %. Vous devez y échapper comme ceci:

date --date="7 days ago" "+\%Y-\%m-\%d"

Voir ici pour plus de détails:

http://www.ducea.com/2008/11/12/using-the-character-in-crontab-entries/

3
Luciano

Je veux ajouter 2 points que j'ai appris:

  1. Les fichiers de configuration Cron placés dans /etc/cron.d/ ne doivent pas contenir de point (.). Sinon, il ne sera pas lu par cron.
  2. Si l'utilisateur qui exécute votre commande n'est pas dans/etc/shadow. Il ne sera pas autorisé à programmer cron.

Refs:

  1. http://manpages.ubuntu.com/manpages/xenial/en/man8/cron.8.html
  2. https://help.ubuntu.com/community/CronHowto
1
Sang Nguyen

J'ai rencontré le même problème où les crons ne fonctionnent pas. Nous avons corrigé en changeant les permissions et le propriétaire par Crons a rendu le propriétaire de la racine, comme nous l'avions mentionné dans crontab ET Cronjobs 644 permission donnée

0
Sachin Patil

J'ai trouvé une autre raison pour laquelle la crontab de l'utilisateur ne fonctionne pas: le nom d'hôte n'est pas présent dans le fichier hosts:

user@ubuntu:~$ cat /etc/hostname
ubuntu

Maintenant le fichier hosts:

user@ubuntu:~$ cat /etc/hosts
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

C'est sur un Ubuntu 14.04.3 LTS, la façon de le réparer est de ajouter le nom d'hôte au fichier hosts donc cela ressemble à quelque chose comme ça:

user@ubuntu:~$ cat /etc/hosts
127.0.0.1 ubuntu localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
0
Javi Romero

Pour moi, la solution a été que le fichier que cron essayait d’exécuter se trouvait dans un répertoire chiffré, plus précisément un répertoire utilisateur sur/home /. Bien que la crontab ait été configurée en tant qu'utilisateur root, le script en cours d'exécution se trouvant dans un répertoire utilisateur chiffré de/home/cron ne pouvait lire ce répertoire que lorsque l'utilisateur était réellement connecté. Pour voir si le répertoire est chiffré, vérifiez si ce répertoire existe:

/home/.ecryptfs/<yourusername>

si c'est le cas, vous avez un répertoire personnel crypté. 

La solution pour moi était de déplacer le script dans un répertoire non = crypté et tout fonctionnait correctement.

0
theINtoy