On Mon, Oct 20, 2014 at 6:17 AM, Roberto De Ioris <[email protected]> wrote:
> > > Hi, > > I've been experimenting with uWSGI's graceful reloading. My toy example > is > > in <https://github.com/shamer/uwsgi_rolling_restart>. > > > > I've followed the "The Zerg Dance" instructions at < > > > http://uwsgi-docs.readthedocs.org/en/latest/articles/TheArtOfGracefulReloading.html > >. > > There seems to be a race between the hook-accepting1-once writefifo to > the > > new.fifo and the master opening the master-fifo. > > > you mean the fifo is not there when the accepting1-once phase is executed ? > > Are you able to manage/see the fifo after the instance is spawned ? > The new.fifo can't be opened O_WRONLY|O_NONBLOCK when the accepting1-once phase is executed. By setting breakpoints in gdb it looks like the following is happening: master 1) The zerg instance master is started in uwsgi_setup master 2) The workers are spawned from core/wsgi.c:3183 worker 1) The first worker process runs the accepting1-once hook master 3) the master opens the "run/new.fifo" in the master_loop on core/master.c:358 Here is the output I get starting a zerg instance using the writefifo hook. I've included some "uwsgi_log" statements around the hook and master_fifo acquisition. shamer@isengard ~/src/uwsgi_rolling_restart (master) $ ~/src/uwsgi/uwsgi --ini conf/uwsgi_zerg.conf [uWSGI] getting INI configuration from conf/uwsgi_zerg.conf open("./python_plugin.so"): No such file or directory [core/utils.c line 3659] !!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!! *** Starting uWSGI 2.0.7 (64bit) on [Mon Oct 20 19:51:55 2014] *** compiled with version: 4.9.1 20140903 (prerelease) on 19 October 2014 19:54:46 os: Linux-3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 nodename: isengard machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 8 current working directory: /home/shamer/src/uwsgi_rolling_restart detected binary path: /home/shamer/src/uwsgi/uwsgi your processes number limit is 48016 your memory page size is 4096 bytes detected max file descriptor number: 1024 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi zerg socket 0 attached to INET address 127.0.0.1:32967 fd 4 zerg sockets attached Python version: 3.4.2 (default, Oct 8 2014, 13:44:52) [GCC 4.9.1 20140903 (prerelease)] *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x1b91d00 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 654912 bytes (639 KB) for 8 cores *** Operational MODE: preforking *** WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1b91d00 pid: 11825 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 11825) spawned uWSGI worker 1 (pid: 11827, cores: 1) spawned uWSGI worker 2 (pid: 11828, cores: 1) spawned uWSGI worker 3 (pid: 11829, cores: 1) running "writefifo:./run/new.fifo 1" (accepting1-once)... failed to open fifo ./run/new.fifo, -1 open("./run/new.fifo"): No such device or address [core/hooks.c line 127] spawned uWSGI worker 4 (pid: 11830, cores: 1) spawned uWSGI worker 5 (pid: 11831, cores: 1) spawned uWSGI worker 6 (pid: 11832, cores: 1) spawned uWSGI worker 7 (pid: 11833, cores: 1) spawned uWSGI worker 8 (pid: 11834, cores: 1) opening fifo ./run/new.fifo
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
