Celerybeat container fails to start #1793
Comments
|
Potential duplicate of #1146? |
|
I'm not sure to be honest. I debugged this the best I could. As far as I can tell the celerybeat code detects a bad schedule file, deletes it, and then carries on (https://github.com/celery/celery/blob/v4.2.1/celery/beat.py#L484). So a bad schedule file shouldn't be a problem. Granted, it sure seems to be based on the logs. I also tried deleting the schedule file in the Docker start file right before celery beat is started ( here https://github.com/pydanny/cookiecutter-django/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/compose/local/django/celery/beat/start#L7). That got rid of the initial logs mentioning removing the corrupted schedule file, but the rest of the errors persisted. |
Also tried same thing, removing that line did not help really. |
|
I got exactly the same error on a Vagrant dev environment. Celery uses dbm for persistent storage, which is built on top of the gdbm C library. Some testing has revealed that this works when creating or opening files on a native filesystem but not on a mounted filesystem. For example, here's what I was seeing on my Vagrant environment: >>> import dbm
>>> db = dbm.open('/tmp/foo.db', 'c')
>>> db = dbm.open('/home/vagrant/reggie-formula/foo.db', 'c')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.6/dbm/__init__.py", line 94, in open
return mod.open(file, flag, mode)
_gdbm.error: [Errno 22] Invalid argumentThis Our fix in our Vagrant project was the change the Celery configuration to store the scheduler db file in a native filesystem instead of a mounted filesystem. We happened to use |
|
Getting rid of this error by changing However, I'm not sure this is the correct fix. After reading the celery configuration, perhaps we config django-celery-beat and use such provider for the beat-scheduler. |
|
Has anyone got a fix for this issue? I've spent a week trying to rectify |
|
help.....killl me..... |
|
Add And change Then This change will set Celery to use Django scheduler database backend. |
|
@xgenvn in case this is relevant: I ended up here with a different issue (I upgraded to python 3.7 and ran into this celery/celery#4849) but hopefully a new release will come out soon as a fix for various issues celery/celery#5180 |
|
The template now uses django-celery-beat as scheduler out of the box in #2084, which should avoid this from happening. Closing this. |
What happened?
Using an out of the box cookiecutter-django project, with default generation options, except for enabling docker and celery. When running the project, the celerybeat container fails to start.
What should've happened instead?
The celerybeat container should start successfully.
Steps to reproduce
Project generation options (all default, except enable docker and celery)
celerybeat logs from docker up
The text was updated successfully, but these errors were encountered: