Файл Crontab Python не работает [дубликат]

Question

Файл Crontab Python не работает [дубликат]

Используя ES2017, вы должны иметь это как объявление функции

async function foo() {
    var response = await $.ajax({url: '...'})
    return response;
}

и выполнить его следующим образом.

(async function() {
    try {
        var result = await foo()
        console.log(result)
    } catch (e) {}
})()

Или синтаксис Promise

foo().then(response => {
    console.log(response)

}).catch(error => {
    console.log(error)

})

20

python linux terminal cron

задан Roshan Bhandari 30 March 2014 в 12:41

8 ответов

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

Никогда не используйте относительный путь в сценариях 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

Никогда не подавляйте код crontab вместо использования почтового сервера и проверяйте почту для пользователя. Это дает более четкое представление о том, что происходит.

6

ответ дан ifly6 5 September 2018 в 08:08

1

– Roshan Bhandari 31 March 2014 в 07:57
2

– JulianHarty 14 December 2014 в 10:35
3

– tripleee 22 July 2018 в 14:20

Я нашел другую причину, по которой пользовательский 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

0

ответ дан Javi Romero 5 September 2018 в 08:08

Другая причина, по которой 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-записи /

3

ответ дан Luciano 5 September 2018 в 08:08

1

– Utku 17 October 2017 в 05:31

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

0

ответ дан Sachin Patil 5 September 2018 в 08:08

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

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

Refs:

1

ответ дан Sang Nguyen 5 September 2018 в 08:08

1

– tripleee 22 July 2018 в 14:19

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

/home/.ecryptfs/<yourusername>

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

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

0

ответ дан theINtoy 5 September 2018 в 08:08

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

-2

ответ дан user2981475 5 September 2018 в 08:08

Другие вопросы по тегам:

python linux terminal cron

Похожие вопросы:

score 82 · Accepted Answer

ВТФ ?! Моя cronjob не запускается?!

Вот руководство по проверочным спискам для отладки не запущенных cronjobs:

Выполняется ли демон Cron? Запустите ps ax | grep cron и найдите cron. Debian: service cron start или service cron restart
Работает cron? * * * * * /bin/echo "cron works" >> /tmp/file Синтаксис правильный? Смотри ниже. Вы, очевидно, должны иметь доступ на запись к файлу, на который вы перенаправляете вывод. Уникальное имя файла в /tmp, которое в настоящее время не существует, всегда должно быть доступно для записи.
Является ли команда автономной? Проверьте, есть ли у сценария ошибка, выполнив сухой прогон в CLI при тестировании вашей команды, проверьте, как пользователь, чей crontab, который вы редактируете, может не быть вашим логином или root
работа? Проверьте ошибки /var/log/cron.log или /var/log/messages. Ubuntu: grep CRON /var/log/syslog Redhat: /var/log/cron
Проверять флажки разрешения на выполнение в команде: chmod +x /var/www/app/cron/do-stuff.php, если вы перенаправляете вывод своей команды в файл, убедитесь, что у вас есть разрешение на запись в этот файл / directory
Проверка путей проверяет, что строка she-bangs / hashbangs не зависит от переменных среды, таких как PATH, поскольку их значение, вероятно, не будет таким же в cron, как в интерактивном сеансе
Не подавлять вывод, в то время как обычно используется отладка, это подавление: 30 1 * * * command > /dev/null 2>&1 повторно включить стандартный вывод или стандартный вывод сообщения об ошибке

Все еще не работает? Yikes!

Поднять уровень отладки cron Debian в /etc/default/cron установить EXTRA_OPTS="-L 2" service cron restart tail -f /var/log/syslog, чтобы увидеть скрипты, выполненные Ubuntu в /etc/rsyslog.d/50-default.conf, добавить или прокомментировать cron.crit /var/log/cron.log перезагрузить logger sudo /etc/init.d/rsyslog reload перезапустить cron open /var/log/cron.log и посмотреть подробный вывод ошибки Напоминание: отключить уровень журнала, когда вы закончите с отладкой
Запустить cron и снова проверить файлы журнала

Синтаксис Cronjob

# Minute  Hour  Day of Month      Month         Day of Week    User Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  

    0       2       *             *                *          root /usr/bin/find

Этот синтаксис является правильным только для пользователя root. Синтаксис обычного пользователя crontab не имеет поля User (обычные пользователи не могут запускать код как любой другой пользователь);

# Minute  Hour  Day of Month      Month         Day of Week    Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  

    0       2       *             *                *          /usr/bin/find

Команды Crontab

crontab -l Список всех задач пользователя cron.
crontab -e для конкретного пользователя: crontab -e -u agentsmith Запускает сеанс редактирования вашего файла crontab. Когда вы выходите из редактора, измененный crontab устанавливается автоматически.
crontab -r Удаляет запись crontab из буферизатора cron, но не из файла crontab.