> 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

Reply via email to