runserver as daemon

[Charlie La Mothe <charlie@…>]

Adds --daemonize option to runserver.

Simply adding a '&' to the end of a runserver call isn't enough.. it will kill the process when you log out of the shell.
So I created this patch, which utilizes django.utils.become_daemon

[Simon G. <dev@…>]

Looks good, but the help_text message (line #1587) needs to be updated, and it'll need a brief line or two in the django-admin docs (django-admin.txt)

[Charlie La Mothe <charlie@…>]

Oh wow, right, can't believe I didn't change the help_text :P

Here is a fixed patch, and it's updated for the latest revision of management.py as well.

[Malcolm Tredinnick]

The development server isn't robust enough to be run as a daemon (for example, there are a few ways to cause errors that will crash it). Something like this would be promoting false expectations, I feel. It's simply not designed to be used like this. I'm -1 on including this at the moment.

[Charlie La Mothe <charlie@…>]

I'm using the development server with lighttpd (through mod_proxy) for development on my production server. I run a seperate codebase for production, using scgi.
When I update some code here in my TextMate, I commit to the development branch, then my server automatically updates the development branch on the server, and the development server reloads the site.

Now you can see how daemonizing it can be handy... doing a runserver every time I want to use the dev server isn't something I want to do, when I'm using the dev server very often.

I see how this could lead to false expections, although as far as I know, the server as a daemon is just as robust as the server running in a shell.

So if this doesn't get incorporated, no big deal, but I hope you can see why I use this and why I'll probably add it myself to every django install I use on a remote server.

[Collin Grady]

+1 here, I always leave runserver in the background for a few projects I tool around with regularly, so I can edit/reload easier, and it would be nice if you could daemonize it automatically (preferably with a pid file like runfcgi as well)

[Jacob]

The development server isn't a real server. Letting it in the backround will just encourage its use that way, which we don't at all want. There's enough ways to daemonize something -- ​daemontools is my personal favorite -- if folks insist. This shouldn't be part of Django, though.

[arbales]

Replying to jacob:

The development server isn't a real server. Letting it in the backround will just encourage its use that way, which we don't at all want. There's enough ways to daemonize something -- ​daemontools is my personal favorite -- if folks insist. This shouldn't be part of Django, though.

I totally understand where you're coming from, but it'd be a helpful feature for more than one of us, ands it's something that other tools in the ecosystem already support; I think a lot of us (if not then, just me) expect this functionality. Please reconsider!

[Honza Král]

please don't reopen tickets without new evidence or reasons. If you are disappointed in the wontfixing, bring it up on the mailing list and discuss it there, thanks!

btw. you could try running gunicorn, cherrypy's server or just doing:

./manage.py runserver > /dev/null 2>&1 &