Opened 17 years ago

Closed 14 years ago

#4996 closed (wontfix)

runserver as daemon

Reported by: Charlie La Mothe <charlie@…> Owned by: nobody
Component: django-admin.py runserver Version: dev
Severity: Keywords: daemonize development server runserver
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (2)

patch.diff (2.4 KB ) - added by Charlie La Mothe <charlie@…> 17 years ago.
patch.2.diff (2.6 KB ) - added by Charlie La Mothe <charlie@…> 17 years ago.

Download all attachments as: .zip

Change History (11)

by Charlie La Mothe <charlie@…>, 17 years ago

Attachment: patch.diff added

comment:1 by Simon G. <dev@…>, 17 years ago

Needs documentation: set
Patch needs improvement: set
Triage Stage: UnreviewedAccepted

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)

comment:2 by Charlie La Mothe <charlie@…>, 17 years ago

Needs documentation: unset
Patch needs improvement: unset

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.

by Charlie La Mothe <charlie@…>, 17 years ago

Attachment: patch.2.diff added

comment:3 by Malcolm Tredinnick, 17 years ago

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.

comment:4 by Malcolm Tredinnick, 17 years ago

Triage Stage: AcceptedDesign decision needed

comment:5 by Charlie La Mothe <charlie@…>, 17 years ago

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.

comment:6 by Collin Grady, 16 years ago

+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)

comment:7 by Jacob, 16 years ago

Resolution: wontfix
Status: newclosed

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.

in reply to:  7 comment:8 by arbales, 14 years ago

Resolution: wontfix
Status: closedreopened

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!

comment:9 by Honza Král, 14 years ago

Resolution: wontfix
Status: reopenedclosed

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 &
Note: See TracTickets for help on using tickets.
Back to Top