I am using Lighttpd + FastCGI + Django on a dev machine. I start FastCGI server via manage.py's command line option.
Problem is that I do make changes to sources quite often and I need to get FastCGI to pick up those changes automatically, just as "./manage.py runserver" does.
Is there a command-line option for that, perhaps, or any other solutions?
Have you looked at the code in the runserver part of manage.py that does the monitoring? I see no reason you could not just copy-paste that code into a custom manage.py script and set it to run the lighty restart command when changes were detected.
Alternatively, you could run a separate python program that did the restart using a package like pyinotify:
http://trac.dbzteam.org/pyinotify
I'm wondering if anyone has ever gotten this to work? I have tried implementing a reload mechanism using django's autoreload.py, unfortunately, I get errors when the fork occurs like:
django/core/servers/fastcgi.py", line 180, in runfastcgi
WSGIServer(WSGIHandler(), **wsgi_opts).run()
File "build/bdist.freebsd-6.4-RELEASE-p9-amd64/egg/flup/server/fcgi_fork.py", line 140, in run
File "build/bdist.freebsd-6.4-RELEASE-p9-amd64/egg/flup/server/preforkserver.py", line 119, in run
File "build/bdist.freebsd-6.4-RELEASE-p9-amd64/egg/flup/server/preforkserver.py", line 450, in _installSignalHandlers
ValueError: signal only works in main thread
My ideal setup would be to be able to reload/kill my fcgi process and start a new one after each time a code change is detected, similar to how django does this with their internal server. I also tried removing the threading from autoreload.py that would get past this error, but it does not seem to run the server properly (still investigating that).
Perhaps someone has tried CherryPies autoreload.py in the settings.py file for django?
Related
I think this is a simple fix, but I've deployed quite a few Django apps to Heroku and I still can't figure out what's going on.
Accessing https://dundjeon-finder.herokuapp.com/ gives me a 500 error when using the browser/curl, but if I shell into the app using heroku run ./manage.py shell I can render the views no problem. My logs aren't telling me anything (just that the response is 500) despite DEBUG being set to True, and Sentry isn't receiving an error (it has previously when the database env variable was set badly), so I'm assuming it's something to do with the way the request works.
The repo is public, any help would be much appreciated! The settings file is here.
Well it was because of using asgi instead of wsgi. I'm not sure why that caused the errors, but will do some more searching.
Django 3.0 is adding asgi / async support and with it a guard around making synchronous requests in an async context. Concurrently, IPython just added top level async/await support, which seems to be running the whole interpreter session inside of a default event loop.
Unfortunately the combination of these two great addition means that any django ORM operation in a jupyter notebook causes a SynchronousOnlyOperation exception:
SynchronousOnlyOperation: You cannot call this from an async context - use a thread or sync_to_async.
As the exception message says, it's possible to wrap each ORM call in a sync_to_async() like:
images = await sync_to_async(Image.objects.all)()
but it's not very convenient, especially for related fields which would usually be implicitly resolved on attribute lookup.
(I tried %autoawait off magic but it didn't work, from a quick glance at the docs I'm assuming it's because ipykernels always run in an asyncio loop)
So is there a way to either disable the sync in async context check in django or run an ipykernel in a synchronous context?
For context: I wrote a data science package that uses django as a backend server but also exposes a jupyter based interface on top of the ORM that allows you to clean/annotate data, track machine learning experiments and run training jobs all in a jupyter notebook.
It works for me
os.environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = "true"
BTW, I start my notebook using the command
./manage.py shell_plus --notebook
Contrary to other answers I'd suggest just running from the shell as:
env DJANGO_ALLOW_ASYNC_UNSAFE=true ./manage.py shell_plus --notebook
and not modifying any config files or startup scripts.
The advantage of doing it like this is that these checks still seem useful to have enabled almost everywhere else (e.g. when debugging locally via runserver or when running tests). Disabling via files would easily disable these in too many places negating their advantage.
Note that most shells provide easy ways of recalling previously invoked command lines, e.g. in Bash or Zsh Ctrl+R followed by notebook would find the last time you ran something that had "notebook" in. Under the fish shell just type notebook and press the up arrow key to start a reverse search.
For now I plan on just using a forked version of django with a new setting to skip the async_unsafe check. Once the ORM gets async support I'll probably have to rewrite my project to support it and drop the flag.
EDIT: there's now a PR to add an env variable (DJANGO_ALLOW_ASYNC_UNSAFE) to disable the check (https://github.com/django/django/pull/12172)
I added
os.environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = "true" code in the setting.py of your project all the way down to the file and then
command python3 manage.py shell_plus --notebook
if you are using python3 or use python
That's it. worked for me.
I'm importing a library with my code that gives me the
NotImplementedError: gevent is only usable from a single thread
the library is internal so I can't share it unfortunately.
I managed to solve this for the Django development server by adding:
import gevent.monkey
gevent.monkey.patch_all(signal=False, httplib=False)
as the first two lines of my manage.py file after the shebang. Then I got to deploying it on apache with mod_wsgi and tought that it would be enough to have it as the first two lines of my wsgi.py-file. This was wrong. I think I've tried everything now, does anyone have any idea of what to do?!
Any ideas of a file that is executed before the wsgi.py file where I could try the monkey patch?
I did not manage to solve this problem, but I managed to replace the two gevent client to other client types which made the problem go away...
I'm using the django celery task queue, and it works fine in development, but not at all in wsgi production. Even more frustrating, it used to work in production, but I somehow broke it.
"sudo rabbitmqctl status" tells me that the rabbitmq server is working. Everything also seems peachy in django: objects are created, and routed to the task manager without problems. But then their status just stays as "queued" indefinitely. The way I've written my code, they should switch to "error" or "ready," as soon as anything gets returned from the celery task. So I assume there's something wrong with the queue.
Two related questions:
Any ideas what the problem might be?
How do I debug celery? Outside of the manage.py celeryd command, I'm not sure how to peer into its inner workings. Are there log files or something I can use?
Thanks!
PS - I've seen this question, but he seems to want to run celery from manage.py, not wsgi.
After much searching, the most complete answer I found for this question is here. These directions flesh out the skimpy official directions for daemonizing celeryd. I'll copy the gist here, but you should follow the link, because Michael has explained some parts in more detail.
The main idea is that you need scripts in three places:
/etc/init.d/celeryd
/etc/default/celeryd
myApp/settings.py
Settings.py appears to be the same as in development mode. So if that's already set up, there are four steps to shifting to production:
Download the daemon script since it's not included in the installation:
https://github.com/celery/celery/tree/3.0/extra/generic-init.d/
Put it in /etc/init.d/celeryd
Make a file in /etc/default/celeryd, and put the variables here into it:
http://docs.celeryproject.org/en/latest/tutorials/daemonizing.html#example-django-configuration
Start the script
This solved my problem.
I think the reason you are not getting any response from celery, is because celeryd server might not be running. You could find out about it by doing ps -ef |grep celeryd. In order to figure out what is the error while trying to run celeryd, you might want to do the following.
In your settings.py file you could give the path to the celery log file CELERYD_LOG_FILE = <Path to the log file>
and while running celeryd server you could specify the level manage.py celeryd -l DEBUG.
I am trying to follow the django tutorial. I am running on windows+eclipse.
When I run python manage.py runserver I get the message Validating models... and afterwards see no progress...
Am I doing something wrong?
I've got my answer in another question: can't get django to work in eclipse + windows
When I ran the server with the --noreload option, I saw that there's an exception thrown. After I fixed that, the output does complete, and says:
Validating models...
0 errors found
Django version 1.2.1, using settings 'XXX'
Development server is running at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.
The shell is running the runserver process, and it won't go back to a command prompt until the server process ends. So, this sounds normal.
Is the server functioning?
You could possibly be importing something in your models.py file that is failing in another file. I had an import in a try/catch clause that caused this behavior. Installing the missing dependency fixed the problem.
This is what you're supposed to see. If you make a request to your test site (via your browser), you will see the log of the request. If you don't see that, then something else is wrong.