Cronjob работает, но не выполняет скрипт python [duplicate]

Наконец, я нашел решение. Ниже приведено решение: -

1. Никогда не используйте относительный путь в сценариях python для выполнения через 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. Никогда не подавляйте код crontab вместо использования почтового сервера и проверяйте почту для пользователя. Это дает более четкое представление о том, что происходит.

Я нашел другую причину, по которой пользовательский crontab не работает: имя хоста отсутствует в файле hosts:

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

Теперь файл 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

Это на Ubuntu 14.04.3 LTS, способ исправить это добавляет имя хоста в файл hosts, чтобы он напоминал что-то вроде этого:

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

Другая причина, по которой crontab не удастся: Специальная обработка символа %.

Из файла 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.

В моем конкретном case, я использовал date --date="7 days ago" "+%Y-%m-%d" для создания параметров для моего скрипта, и он терпел неудачу молча. Я, наконец, узнал, что происходит, когда я проверил syslog и увидел, что моя команда была усечена символом %. Вам нужно избежать этого:

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

Подробнее см. Здесь:

http://www.ducea.com/2008/11/12/ используя-на-символ-в-Crontab-записи /

У меня возникла такая же проблема, когда кроны не работают. Мы исправили изменение прав и владельца владельцем root, созданным Crons, как мы упоминали в разрешении crontab и Cronjobs 644 с [

Я хочу добавить 2 очка, которые я узнал:

1. Файлы конфигурации Cron, помещенные в /etc/cron.d/, не должны содержать точку (.). В противном случае он не будет считаться cron.
2. Если пользователь, выполняющий вашу команду, не находится в / etc / shadow. Невозможно запланировать cron.

Refs:

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

Для меня решение заключалось в том, что файл cron пытался запустить, был в зашифрованном каталоге, более конкретно, в директории user / home /. Хотя crontab был настроен как root, потому что сценарий, запущенный в зашифрованном каталоге пользователя в / home / cron, мог читать этот каталог только в том случае, если пользователь был фактически зарегистрирован. Чтобы узнать, зашифрован ли каталог, проверьте, существует ли этот каталог:

/home/.ecryptfs/<yourusername>

, если это так, у вас есть зашифрованный домашний каталог.

Исправление для меня состояло в том, чтобы переместить скрипт в не зашифрованный каталог, и каждый из них работал нормально.

Иногда команда, с которой должен работать cron, находится в каталоге, где cron не имеет доступа, как правило, в системах, где разрешения пользователей домашних каталогов - 700, а команда - в этом каталоге.