3đź‘Ť
âś…
The problem here is that when you run it as your user, virtualenv already has proper environment activated for your user “myuser” and it pulls packages from /home/myuser/.virtualenvs/myproject/…
When you do sudo /etc/init.d/celeryd start you are starting celery as root which probably doesn’t have virtualenv activated in /root/.virtualenvs/ if such a thing even exists and thus it looks for python packages in /usr/lib/… where your default python is and consequently where your celery is not installed.
Your options are to either:
- Replicate the same virtualenv under root user and start it like you tried with sudo
- Keep virtualenv where it is and start celery as your user “myuser” (no sudo) without using init scripts.
- Write a script that will
su - myuser -c /bin/sh /home/myuser/.virtualenvs/myproject/bin/celeryd
to invoke it from init.d as a myuser. - Install supervisor outside of virtualenv and let it do the dirtywork for you
Thoughts:
- Avoid using root for anything you don’t have to.
- If you don’t need celery to start on boot then this is fine, wrapped in a script possibly.
- Plain hackish to me, but works if you don’t want to invest additional 30min to use something else.
- Probably best way to handle ALL of your python startup needs, highly recommended.
👤enticedwanderer
9đź‘Ť
Maybe you just set a wrong DJANGO_SETTINGS_MODULE:
try: DJANGO_SETTINGS_MODULE=”settings” <-> DJANGO_SETTINGS_MODULE=”project.settings”
👤vutran
- [Django]-Django deep serialization – follow reverse foreign key constraints
- [Django]-Can this result in a deadlock in django + postgres?
- [Django]-Django Postgresql syncdb error
- [Django]-How to get the filename and line number of a Django template error when calling render()?
Source:stackexchange.com