> So, ordinarily when a vassal starts up, the master starts up *outside* the > chroot, and then chroots itself, and then starts the worker, am I right?
yes, exact > > But when I'm looking at this point, I'm seeing a... worker? or a master? > trying to restart itself? And it's never going to work, since it's inside > the chroot. the master "binary patch" itself (execve() itself), it is the only process you need to care about. If you want a graceful reload (read: sockets are left opened) it needs to know the new paths (related to the chroot) > > But later on, it does a proper restart, and everything works OK. yes because the emperor waits for process exit before respawning it (so the race condition is avoided as vacuum is called by the master) > > SO, what causes the intermediate chrooted reload, which is never going to > work? a "touch" of the config, a SIGHUP or a uwsgi.reload() called by the customer > And who causes the proper un-chrooted restart? as the graceful reload fails, uwsgi calls exit(1), this call triggers the vacuum and finally it is destroyed. Once destroyed the Emperor starts a new "virgin" vassal. Is there any way of > disabling the intermediate one? > exit-on-reload = true (in each vassal) will avoid it, leaving the whole process management to the Emperor (as the vassal will destroy itself everytime) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
