> Cool, so setting exit-on-reload = true reduces the amount of faffing that > the vassal does trying to reload itself: > > Gracefully killing worker 1 (pid: 2338)... > worker 1 buried after 1 seconds > uWSGI: GAME OVER (insert coin) > chdir(): No such file or directory [core/uwsgi.c line 1326] > VACUUM: unix socket /var/sockets/admin.pythonanywhere.com/socket > removed. > limiting number of processes to 32... > [...normal vassal startup follows] > > So it now does much less of chdir() no such file or directory, but still > one. Love the "insert coin" btw.
That is the chdir() the vacuum tries to do in the case your unix socket has a relative path. It is not your case so you can safely ignore it. > > But I think the important thing for us is that there is no race condition > possible - the emperor waits for the old process to die, it does the > vacuum, > and only after that does the emperor start a new master. > > Now what about this: if I restart the **emperor**, I see this output: > > reloading the emperor means reloading its vassals, so i suppose you stop and start it. This can absolutely cause race conditions (and the more vassals you have the more races you will get). A solution can be the --flock/--flock-wait approach. the first one exit an instance if another one is holding a lock on a file. The second one will wait til the lock is released. I do not know which of the two approaches is better, i suggest you to try both and then make a choice: flock = %p or flock-wait = %p (%p maps to the vassal config, i think it is a good trick for your case= -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
