Opened 8 years ago

Closed 5 years ago

#4996 closed (wontfix)

runserver as daemon

Reported by: Charlie La Mothe <charlie@…> Owned by: nobody
Component: django-admin.py runserver Version: master
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: UI/UX:

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@…> 8 years ago.
patch.2.diff (2.6 KB) - added by Charlie La Mothe <charlie@…> 8 years ago.

Download all attachments as: .zip

Change History (11)

Changed 8 years ago by Charlie La Mothe <charlie@…>

comment:1 Changed 8 years ago by Simon G. <dev@…>

  • Needs documentation set
  • Needs tests unset
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

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 Changed 8 years ago by Charlie La Mothe <charlie@…>

  • 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 8 years ago by Charlie La Mothe <charlie@…>

comment:3 Changed 8 years ago by mtredinnick

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 8 years ago by mtredinnick

  • Triage Stage changed from Accepted to Design decision needed

comment:5 Changed 8 years ago by 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.

comment:6 Changed 7 years ago by cgrady

+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: Changed 7 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to 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 in reply to: ↑ 7 Changed 5 years ago by arbales

  • Resolution wontfix deleted
  • Status changed from closed to 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 5 years ago by Honza_Kral

  • Resolution set to wontfix
  • Status changed from reopened to 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 &
Note: See TracTickets for help on using tickets.
Back to Top