See this blog post: http://rambleon.usebox.net/post/3279121000/how-to-gracefully-restart-django-running-fastcgi TL;DR : just send SIGHUP to flup process (pidfile option to fastcgi), like this: kill -SIGHUP `cat /path/to/flup.pid` I suggest using Gunicorn, as it handles graceful reloads better than flup in my experience (trought newest editions of flup handle graceful reloads with SIGUSR). Also: graceful reload is impossible when you are running database schema changes as that is not atomic process. Put some nice 502 error page like: where are updating teh codez, drink coffeee! On Mar 24, 8:56 am, Jani Tiainen <rede...@gmail.com> wrote: > Hi, > > First at all, if you're working with real high availability system you already > have resolved most of the single point of failure problems, and other non- > django related issues (like broken hardware, broken network connections etc.) > > And by looking what you're experiencing now indicates that you haven't done > not your homework about real high availability systems. > > And finally about Django: > > Django itself by design uses share nothing architecture, so if you don't > deliberately program something that is shared it won't cause any side-effects. > > When run behind webservers you must shut down all instances gracefully (let > them complete last request before closing them down) to avoid loss of data. > > On Thursday 24 March 2011 08:29:00 Shamail Tayyab wrote: > > > Hi, > > > We have a setup in which we can't afford downtime (even while > > deployment). > > > Our setup is based on lighttpd + django (on fcgi via flup). What my > > problem is, when we restart django, the site goes down for about a > > couple of seconds (and all API calls to DB remains incomplete > > resulting in 500.html being rendered for users). > > > We need a setup in which we can restart our system in a safe way. > > > As an initial thought, instead of 1 site instance, lets have 2, then > > use lighty's load balancing to have both the instances run, then drop > > the previous instance. > > > Is this feasible? Will it lead to inconsistencies? How can I still > > ensure that calls on previous instance completely stops before > > dropping it? > > > Any other way to do this? > > > Tx
-- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
