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.
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:
...brutally killing workers...
lost connection with my emperor !!!
limiting number of processes to 32...
your processes number limit is 32
your memory page size is 4096 bytes
detected max file descriptor number: 123456
building mime-types dictionary from file /etc/mime.types...532 entry
found
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address
/var/sockets/admin.pythonanywhere.com/socket fd 3
Python version: 2.7.4 (default, Apr 19 2013, 18:30:41) [GCC 4.7.3]
*** Python threads support is disabled. You can enable it
with --enable-threads ***
Python main interpreter initialized at 0x2237180
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
setting request body buffering size to 65536 bytes
mapped 333952 bytes (326 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x2237180
pid: 2362 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 2362)
spawned uWSGI worker 1 (pid: 2365, cores: 1)
chdir(): No such file or directory [core/uwsgi.c line 1326]
VACUUM: unix socket /var/sockets/admin.pythonanywhere.com/socket
removed.
And now we do have a problem -- somehow the socket vacuum has happened after
the vassal restarted, and now the vassal site will 502...
HP
--
Harry Percival
Developer
[email protected]
PythonAnywhere - a fully browser-based Python development and hosting
environment
<http://www.pythonanywhere.com/>
PythonAnywhere LLP
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number OC378414.
Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK
-----Original Message-----
From: Roberto De Ioris
Sent: Wednesday, August 21, 2013 7:01 PM
To: uWSGI developers and users list
Subject: Re: [uWSGI] UWSGI vassal graceful shutdown... possible race?
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
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
