On Thu March 7 2013 11:50:40 Roberto De Ioris wrote:
> > On Thu March 7 2013 06:44:31 Damjan wrote:
> >> > That is because the HUP sent on the emperor does not "binary-patch" it
> >> > but only trigger a respawn of all of its vassals. To batch an emperor
> >> > you have to shuwtdown it (taking down all of the vassals) and restart.
> >> 
> >> Which is why you should use --master with --emperor
> >> 
> >> HUP-ing the master will re-exec the master and restart the emperor
> > 
> > Unfortunately that brings me back to one of the issues I mentioned
> > earlier.
> > When I use --master and --emperor and do a reload after the binary
> > upgrade,
> > the sock files for the sites bein managed by emperor are deleted but not
> > recreated when it restarts.
> 
> the Emperor does not manage sockets, they are created by vassals.
> 
> The only socket created by the emperor is the stats one (if configured)

I understand that. What I don't understand is why the vassals are not reloaded 
correctly in this case.
Is it because of the binary change?

> > Also, I get the impression using this method would not be that graceful
> > anyway
> > since the emperor would be restarted stopping all the vassals.
> > Would that not be correct?
> 
> when you restart the emperor all of your vassals are restarted (by design).
> 
> The whole idea is that the Emperor is spawned on server startup (or in the
> container in the case of PaaS) and then you never touch it. If you need to
> upgrade such a vital piece (the Emperor) you'd better to schedule a
> downtime (or better this is what i would do ;).

I am fine with doing this as well. I will look into scheduling it differently.

> Again, i am curious, why do you have such a need ?

I was just curious to see whether there was a way to do it the same as nginx 
does to limit the amount of down time from the restart. I know it will be a 
small amount, but was wanting to see if it could be done.

Thank you for your help.
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to