Opened 15 years ago
Closed 12 years ago
#4996 closed (wontfix)
runserver as daemon
Reported by: | 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)
Change History (11)
Changed 15 years ago by
Attachment: | patch.diff added |
---|
comment:1 Changed 15 years ago by
Needs documentation: | set |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
comment:2 Changed 15 years ago by
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.
Changed 15 years ago by
Attachment: | patch.2.diff added |
---|
comment:3 Changed 15 years ago by
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 Changed 15 years ago by
Triage Stage: | Accepted → Design decision needed |
---|
comment:5 Changed 15 years ago by
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 Changed 14 years ago by
+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 follow-up: 8 Changed 14 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
comment:8 Changed 12 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
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 &
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)