Не работает crontab django

Команда Crontab Django Management вроде бы запускается, но ничего не происходит

Я определил команду управления django, которая импортирует некоторые данные в базу данных моего приложения. Я запускаю ее с помощью crontab. Примечание: все находится внутри контейнера docker. Эта команда отлично работает, когда я использую ее вручную в оболочке моего контейнера. Однако когда crontab пытается запустить ее, ничего не происходит.

Моя строка crontab следующая :

(Я поместил свой код в /code, потому что в то время это казалось хорошей идеей.)

Я знаю, что crontab вызывает мою команду, потому что при ее выполнении отображается /var/log/syslog. Я не могу понять причину, по которой ничего не происходит.

В качестве теста в методе «handle» моей команды я написал print(«handling command») в первой строке, затем добавил >> /code/cron.log в конце моей строки crontab. Текст не появился в файле.

Answers: 1

Answered by PleaseHelp, 19 августа 2021 г. 19:21

Что остановило выполнение cron, так это то, что я запустил команду в subprocess.Popen, которая не использовала абсолютные пути. Поэтому Popen (который я не поместил внутрь try . except) разбился при вызове с небольшими переменными окружения cron.

Я бы не подумал искать там, потому что эта часть кода была вызвана из моего метода AppConfig.ready.

Я надеюсь, что это может кому-то помочь, пожалуйста, скажите мне, если вы считаете, что я должен удалить этот пост, я сделаю это, когда получу уведомление.

Источник

Как заставить django-cron работать автоматически

Я пытаюсь заставить django-cron работать, а его нет. Я выполнил инструкцию здесь, чтобы настроить мой cron, но проблема в том, что моя работа выполняется только тогда, когда я набираю python manage.py runcrons в моей командной строке и работа не запускается каждые 5 минут. Я не знаю, что еще делать. Я прочитал другие документы на crontabs и chronograph , но я смущен. Я устанавливаю crontabs вместе с cron или хронографом или cron работает нормально только с django-cron. Также как я могу запустить свою работу автоматически. В документации здесь я прочитал Now everytime you run the management command python manage.py runcrons all the crons will run if required. Depending on the application the management command can be called from the Unix crontab as often as required. Every 5 minutes usually works for most of my applications. . Что это значит. Что мне здесь не хватает. Я проиграл. HELP

Я должен упомянуть, что я использую pycharm на платформе Windows для запуска django…

Корень вашей проблемы приводит к операционной системе. Веб-сервер не такой деамон, который называет ваши кроны, он просто передает веб-запросы. Для вызова периодических задач в Windows вам необходимо использовать планировщик задач Windows:

Другой способ решить вашу проблему – начать дегуатор сельдерея в режиме извлечения сельдерея.

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

Установите django-crontab вместо этого.

Измените параметры settings.py, чтобы включить django-crontab

создать файл cron.py в каталоге приложения

запускайте это каждый раз, когда вы включаете или обновляете свое задание cron.

запустите локальный сервер, чтобы проверить ваш cron:

Вы можете выполнять программные действия runcrons, например:

Источник

Почему не работает django-crontab из под virtualenv?

Следую инструкции. Если запускать из под virtualenv то работает все ок, в crontab -l выводит следующее

Если запускаю скрипт в командной строке:

Но если я активирую виртуальное окружение, (source /venv/bin/activate) и запускаю

То все работает, скрипт корректно запускается, логгер отключать пробовал, эффекта не дало.

• Вопрос задан более трёх лет назад
• 562 просмотра

Не могли бы Вы внести ряд уточнений в вопрос.

1. Вы устанавливали django-crontab, когда виртуальное окружение было активировано.

2. Вы ожидаете, что всё должно работать без активации виртуального окружения, через обращение к системному python:

ksenofobius, позволю себе немного побыть капитаном очевидность. Если не натолкнёт на решение проблемы — можно меня закидать виртуальными камнями.

logging — модуль стандартной библиотеки Python.

У Вас не возникает ошибки «ImportError: No module named ‘logging'», значит при импорте модуль или пакет с таким именем находится всегда.

Судя по отсутствию ошибок при таком же импорте в интерактивной консоли, у меня функция getLogger имеется в пакете logging как в python 2.7, так и в python 3.5.

Ошибка «AttributeError: module ‘logging’ has no attribute ‘getLogger'», явно указывает что интерпретатор находит модуль или пакет с таким названием, но не находит внутри getLogger.

Положите рядом с manage.py файл со следующим содержанием:

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

Источник

Cron not running django command

I have a django script that should be run at a specified time every day. I am trying to achieve this using crontab . The script is supposed to dump the database, archive it using gzip and upload it to bitbucket .

The following is the relevant part of my crontab file:

When I execute python /my_django_project_path/manage.py database_bu it works perfectly fine. However crontab either does not execute it or something happens along the way. Even weirder, the first crontab command ( update_locations ) is executed perfectly fine.

Reading this question, I have tried the following, without success:

Changing the command to:

Changing the command to:

Adding the following to my script (even though the other one works fine without it):

Running everything through a script that exports the django project settings:

The following in crontab:

Changing the user to both my user and the Apache user ( www-data ).

I have a newline at the end of my crontab file.

UPDATE:

When doing sudo su , running the command manually no longer works. It gets stuck and doesn’t do anything.

The output of tail -f /var/log/syslog is:

UPDATE:

I am using the following .netrc file to prevent git asking for credentials:

The actual code for the backup script is:

UPDATE:

I managed to fix it using Chris Clark’s suggestion of calling the script directly rather than through manage.py. However, I am still interested in what is causing this issue so the bounty is still available.

UPDATE [SOLVED]:

Adding the following line to /etc/environment and running it as my user account rather than root fixed it:

I still wonder why only my user can run it so if anyone has the solution to that, please contribute.

4 Answers 4

Since some version of python /my_django_project_path/manage.py database_bu works for you, it means the problem is with your cron environment , or in the way you have set up your cron and not with the script itself (as in the size of file to be uploaded or network connectivity is not causing the issue).

Firstly, you are running the script as

47 16 * * * root python /my_django_project_path/manage.py database_bu

You are providing it a username root , which is not the same user as your current user, while the shell command worked for your current user. The fact that the same command doesn’t run from root user using sudo su suggests that your root user account is not properly configured anyway. FWIW, scheduling something as root should almost always be avoided because it can lead to weird file permission issues.

So try scheduling your cron job as follows from that current user.

This may still not run the cron job completely. In which case, the problem could be at 2 places — your shell environment is having some variables that are missing from your cron environment, or your .netrc file is not being read properly for credentials, or both.

In my experience, I have found that PATH variable causes the most troubles, so run echo $PATH on your shell, and if the path value you get is /some/path:/some/other/path:/more/path/values , run your cron job like

If this doesn’t work out, check all the environment variables next.

/environment.txt from a normal shell to get all the environment variables set in the shell. Then use the following cron entry * * * * * printenv >

/cron_environment.txt to identify the missing variables from the cron environment. Alternatively, you can use the snippet in a script to get the value of environment from with the script

Compare the two, figure out any other relevant variables which are different (like HOME ), and try using the same within the script/cron entry to check if they work or not.

If things still don’t work out, then I think the remaining problem should be with your bitbucket credentials in .netrc in which saving the username and password. The contents .netrc might not be available in the cron environment.

Instead, create and set up an ssh keypair for your account and let the backup happen over ssh instead of https (Its better if you generate a ssh key without passphrase in this step, to avoid ssh-keys’ gotchas).

Once you have setup the ssh keys, you will accordingly have to edit the existing origin url from .git/config file of your project root (or will have to add a new remote origin_ssh using git remote add origin_ssh url for the ssh protocol).

Note that https urls for the repo is like https://user@bitbucket.org/user/repo.git while the ssh one is like git@bitbucket.org:user/repo.git .

PS: bitbucket , or rather git is not the ideal solution for backups, there are tonnes of threads hanging around for better backup strategies. Also, while debugging, run your crons every minute ( * * * * * ), or at similarly low frequency for faster debugging.

Edit

OP says in the comment that setting the PWD variable worked for him.

PWD=/my_django_project_path/helpers/management/commands to /etc/environment

This is what I had suggested earlier, one of the environment variable available in the shell not being present in cron environment.

In general, crown always runs with a reduced set of environment variable and permission, and setting the right variables will make cron work.

Also since you are using a .netrc file for permissions, it is specific to your account, and therefore that won’t work with any other account (including the sudo account for root ), unless you configure the same setting in your other account as well.

Источник

Использование crontab с django

Мне нужно создать функцию для ежедневного рассылки бюллетеней из crontab. Я нашел два способа сделать это в Интернете:

Сначала — файл, помещенный в папку проекта django:

Я не уверен, что это сработает, и я не уверен, как его запустить. Скажем, он называется run.py, поэтому я должен называть его в cron с помощью 0 0 * * * python /path/to/project/run.py
?

Второе решение — создайте мою функцию отправки в любом месте (как обычную функцию django), а затем создайте run.py script:

И затем в вызове cron: 0 0 * * * python /path/to/project/run.py newsletter.views daily_job()

Какой метод будет работать, или что лучше?

Вариант 1 работает для меня. Обычно я использую script cd для каталога проекта, а затем выполняю «python./script_name.py», чтобы не было таинственных проблем пути. ленив, но он работает последовательно.

Я предлагаю создать вашу функциональность как django-management-command и запустить ее через crontab

если ваша команда send_newsletter , а затем просто

и вам не нужно заботиться о настройке модуля настроек в этом случае/

Предложение Ashok об управлении командами управления через cron работает хорошо, но если вы ищете что-то более надежное, я бы посмотрел в библиотеку, например Kronos:

Предлагаю взглянуть на django-chronograph. В основном, он делает то, что вы хотите, в соответствии с другими предложениями +, это дает вам возможность управлять вашими заданиями cron через панель администратора. Работы Cron должны выполняться как команды django. Затем вы можете запускать все ожидающие задания, вызывая

который должен быть вызван вашим cron.

Существует также django-cron. Он очень прост в использовании, нет ничего другого для установки или настройки.

Однако, я не уверен, как это работает. Я имею в виду, что я не знаю, как выполняются задания и, если они запущены на все, когда никто не делает запрос на сайт. Но вы можете попробовать!

Я написал несколько приложений с командной строкой, используя метод, аналогичный вашему первому варианту. Я предпочитаю делать это таким образом, в отличие от использования переменной среды DJANGO_SETTINGS_MODULE , потому что она больше похожа на обычную программу Python (для меня).

Следует также отметить, что вам не нужно размещать ваш модуль в том же каталоге, что и ваш settings.py ; вы можете использовать абсолютный путь Python вашего модуля настроек:

PEP 8 в любом случае обескураживает относительный импорт.

Я всегда устанавливаю свои приложения Django в пакеты сайта ( /usr/lib64/python2.6/site-packages в Gentoo), поэтому мне не нужно беспокоиться о настройке PYTHONPATH из моих crontab, но я не считаю, что это широко практикуемый метод. Я также хотел бы использовать setuptools Automatic Script Creation, чтобы мои консольные скрипты попадали туда, где они должны быть ( /usr/bin , например) и называются соответственно автоматически. Ваш первый вариант также облегчает это.

Источник