> 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 >
So a "spinning" writefifo here will do the trick, waiting for the fifo to became ready. Can you try this plugin ? https://gist.github.com/unbit/2674313f070673a720e3 (just run "uwsgi --build-plugin spinningfifo.c" to build it) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
