How to run django-cron job in exact time

I can't use celery in my project, only django-cron. I need to run my task 2 times a day:

  • at 11:59 A.M.
  • at 11:59 P.M.

Can I do it? I found only RUN_EVERY (in mins or secs) variable.

Answers


I am familiar with this django-cron: https://github.com/andybak/django-cron

You could set your the actual cronjob that drives django-cron to only run at those times (this would reduce it's usefulness if you want it to run other jobs but would work for the use case you described). In that case your crontab entry should look something like:

59 11,23 * * * /path/to/python /path/to/manage.py cronjobs

With that crontab entry django cron would only be run twice a day at 11:59am and 11:59pm so even if you had specified that a job run every minute it would only run at those times. If the cron-job failed for any reason though, it would not be run for the following 12 hours.

Alternatively, you could set up the job to run every 12 hours

HOUR * 12

After it has run once, manually edit the database to say that the last run was at 11:59 pm or am (whichever is in the future), it will then begin running every 12 hours after that time, so it should always hit at exactly 11:59. In this case if the job failed it would be possible for it to start running at 12:00 or later as it tried to catch back up.

If you are using a different django-cron than the one I mentioned at the beginning then some of these ideas may be applicable, but maybe not. If you are using the one mentioned at the beginning make sure you pull in a recent version of it, I contributed a commit to it 5 days ago which makes it so jobs don't drift through time (i.e. running after 61 minutes instead of 60 etc...), which they were in certain circumstances.


Need Your Help

Triangle with Open-GL doesn't appear?

android opengl-es

I made an activity to display a triangle but while running it shows no triangle;

Under what circumstances can a vtable pointer be null (or 0x1)?

c++ osx gcc crash vtable

I am currently debugging a crashlog. The crash occurs because the vtable pointer of a (c++-) object is 0x1, while the rest of the object seems to be ok as far as I can tell from the crashlog.