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?
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.
But later on, it does a proper restart, and everything works OK.
SO, what causes the intermediate chrooted reload, which is never going to
work? And who causes the proper un-chrooted restart? Is there any way of
disabling the intermediate one?
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 6:43 PM
To: uWSGI developers and users list
Subject: Re: [uWSGI] UWSGI vassal graceful shutdown... possible race?
Hi there uWSGI fans,
We have an emperor setup, with multiple vassals that run in chroots. Each
vassal has a master and one or many workers. They listen on sockets which,
thanks to a little symlink-based magic, are available from inside the
chroot and outside.
We think we’ve got a race condition during vassal reloads, and were
wondering if anyone could help confirm or deny our theory?
When we do a reload, we see output that looks a little like this:
Wed Aug 21 16:55:19 2013 - received message 1 from emperor
...gracefully killing workers...
Gracefully killing worker 1 (pid: 1881)...
worker 1 buried after 1 seconds
binary reloading uWSGI...
chdir() to /etc/uwsgi/vassals
chdir(): No such file or directory [core/master_utils.c line 348]
closing all non-uwsgi socket fds > 2 (max_fd = 123456)...
found fd 3 mapped to socket 0
(/var/sockets/admin.pythonanywhere.com/socket)
running /usr/bin/uwsgi
execvp(): No such file or directory [core/master_utils.c line 449]
chdir(): No such file or directory [core/uwsgi.c line 1326]
VACUUM: unix socket /var/sockets/admin.pythonanywhere.com/socket
removed.
Hi Harry,
this is what happens on uwsgi reload:
1) chdir() to the directory where all started
2) close the file descriptors
3) execve() the original binary
this is what happens to you (caused by the chroot)
1) chdir() fails (/etc/uwsgi/vassals does not exist in the chroot)
2) execve() fails (the executable is not available)
3) exit(1) is called
4) atexit hooks are called (vacuum in your case) to a series of
non'existent directories
How to solve ?
basically you need to instruct uWSGI about the new executable path:
binary-path = path_to_uwsgi
My only doubt is that probably you do not have the uwsgi binary in the
chroot...
Note:
chdir() failures are not fatal, but maybe an option to instruct uWSGI
about the new "cwd" (after the chroot) could be useful
--
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
