Testing if datetime is aware fails

[mikicz]

manager.run(force)
  File "/var/www/hosts/bettersubbox.com/dev/local/lib/python2.7/site-packages/django_cron/__init__.py", line 209, in run
    with self.lock_class(cron_job_class, self.silent):
  File "/var/www/hosts/bettersubbox.com/dev/local/lib/python2.7/site-packages/django_cron/backends/lock/base.py", line 60, in __enter__
    raise self.LockFailedException(self.lock_failed_message())
  File "/var/www/hosts/bettersubbox.com/dev/local/lib/python2.7/site-packages/django_cron/backends/lock/cache.py", line 47, in lock_failed_message
    started = self.get_running_lock_date()
  File "/var/www/hosts/bettersubbox.com/dev/local/lib/python2.7/site-packages/django_cron/backends/lock/cache.py", line 90, in get_running_lock_date
    if not timezone.is_aware(date):
  File "/var/www/hosts/bettersubbox.com/dev/local/lib/python2.7/site-packages/django/utils/timezone.py", line 340, in is_aware
    return value.utcoffset() is not None
AttributeError: 'NoneType' object has no attribute 'utcoffset'
``

Django 1.9, failed once out of thousands of runs...

[tab-cmd]

@mikicz can I have a little more information about your implementation? I am having trouble replicating

[mikicz]

Hi, I think I just followed the tutorial and documentation and did no modyfing, this really occured once after many months of production runtime and never happen since, I don't know if its worth trying to replicate...

[evenicoulddoit]

I also just received this. Interesting,

[tbarbugli]

I think there is a race condition around lock release and lock acquisition failed message.

Say you have 2 processes trying to run the same job A and B

A. acquire lock
A. run job
B. acquire lock
A. release lock
B. read lock value

[msopko81]

I had this error occur today and wanted to say what I saw. I am using this on Windows through the task scheduler and have it set to run every 5 mins. For some reason, Windows did not run the script at 1:50 PM. I think it then tried to run it twice at 1:56 PM.

I also think that the first process messed up the second process in more than 1 way. It was trying to run a job at 1:50 PM that was scheduled for 4 AM. The only time I saw something like this happen, I had an issue with the backend (e.g. database was down so it attempted to run all of the jobs).

So, I guess what I am trying to say is that this issue may be with the OS or with the cache backend.

[agronick]

We run a lot of jobs and I'm getting this error at least every day, sometimes multiple times a day. Any idea when this will be fixed in pip?

[tbarbugli]

@agronick do you have more than 1 process/server running the cron command?

[agronick]

Just one but they run all the time. I think the problem is that maybe 1 out of every 500 jobs finishes between the time when that cache key is checked and when it is read the second time.

[maxim-kht]

Resolved in #130