Closed prymitive closed 12 years ago
i cannot reproduce the problem. This is the config i am using:
[uwsgi] namespace = /ns/001/:testns namespace-keep-mount = /dev/pts socket = :3031 attach-daemon = /usr/sbin/dropbear -j -k -p 1022 -E -F -I 300
i directly run it with the emperor
uwsgi --emperor jail.ini
i login into 1022 and as soon as i touch the file all is destroyed
With config above I couldn't reproduce it either, so I started disabling options in my vassal and it turns out that it only happens when using --cheaper:
[uwsgi]
namespace = /ns/001/:testns
namespace-keep-mount = /dev/pts
socket = :3031
attach-daemon = /usr/sbin/dropbear -j -k -p 1022 -E -F -I 300
processes = 2
cheaper = 1
With some debug logs in core/master.c I've found out that during vassal reload with --cheaper enabled uwsgi.ready_to_reload stops incrementing while I'm logged (and there is extra child process) so it never reaches uwsgi.numproc value that is required for reload.
Can you retry with latest commit ?
Works fine now, thanks
With option below I can run dropbear instance inside my vassal chroot (vassal is using --namespace)
But if I will log in with ssh to this dropbear instance, than during vassal stop or reload uWSGI will hang until this child process is terminated. To solve this we would need to kill all daemon children before or after killing deamon pid, but after a little googling I can't find any way to get all children pids of given parent pid. It seems that it requires /proc parsing and that would be limited to linux only, I have no idea how to implement it on *bsd.
I can leave without it since I can kill dropbear using helper scripts when I reload my vassals, but if it would be grate if uWSGI could handle it by itself. If not then maybe docs should warn about such issues.