> On Fri March 8 2013 13:38:21 Roberto De Ioris wrote: >> Just to be sure you have all the situation clear (and that i have >> understood what you mean ;). >> >> This is how things currently work: >> >> emperor (alone) you send SIGHUP to it and it will start graceful >> reloading >> all of the vassals. >> >> emperor + master, you send SIGHUP to the master the emperor dies and all >> of the vassals are brutally destroyed (will be restarted after the >> master >> binary patching) > > In this case the emperor restarts, but for some reason the vassals are > not. > The sock files for the vassals are not recreated.
Ok, now it is more clear, basically you are hitting a race condition with the old vassals still shutting down and the new one of the new master copy. With tcp socket is not a problem because the second vassal will simply fail until the old one dies. With UNIX socket you could have problems because the new instance overwrite the old socket, and if you have vacuum in place the old one will delete it as soon as it end (yeah, this is a real mess). For such a case i suggest the use of the flock/flock-wait options. That options force instances to lock a file on startup avoding copies to spawn until the lock is released. > >> emperor + master, you send SIGHUP to the emperor and it will start >> graceful reloading all of the vassals. >> >> What you are missing is the possibility to reload the vassals as with >> SIGHUP but with the addition of binary patching the emperor too >> (reloading >> itself) >> >> Am i right ? > > Yes, that is what I was looking for. definitely something to look at in future branches. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
