Hi Roberto,
The spinningfifo plugin works, thanks! The output when using the plugin is
included below. I've also included the output from using "exec + echo".
Would it be useful for me to submit a pull request on github that mentions
this behavior in "the zerg dance" and use of the accepting1-once hook?
Thanks,
Stephen
using "spinningfifo:./run/new.fifo 1" hook
$ ~/src/uwsgi/uwsgi --plugin spinningfifo_plugin.so --ini
conf/uwsgi_zerg.conf
<<<Truncated for readability>>>
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 30294)
spawned uWSGI worker 1 (pid: 30296, cores: 1)
spawned uWSGI worker 2 (pid: 30297, cores: 1)
spawned uWSGI worker 3 (pid: 30298, cores: 1)
running "writefifo:./run/running.fifo 2p" (accepting1-once)...
failed to open fifo ./run/running.fifo, -1
open("./run/running.fifo"): No such device or address [core/hooks.c line
127]
running "spinningfifo:./run/new.fifo 1" (accepting1-once)...
waiting for ./run/new.fifo ...
spawned uWSGI worker 4 (pid: 30299, cores: 1)
spawned uWSGI worker 5 (pid: 30300, cores: 1)
spawned uWSGI worker 6 (pid: 30301, cores: 1)
spawned uWSGI worker 7 (pid: 30302, cores: 1)
spawned uWSGI worker 8 (pid: 30303, cores: 1)
opening fifo ./run/new.fifo
waiting for ./run/new.fifo ...
managing master fifo on fd 24
Tue Oct 21 23:26:45 2014 - active master fifo is now ./run/running.fifo
managing master fifo on fd 24
opening fifo ./run/running.fifo
using "exec:echo 1 > ./run/new.fifo"
$ ~/src/uwsgi/uwsgi --plugin spinningfifo_plugin.so --ini
conf/uwsgi_zerg.conf
<<< Truncated for readability>>>
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 32213)
spawned uWSGI worker 1 (pid: 32221, cores: 1)
spawned uWSGI worker 2 (pid: 32222, cores: 1)
spawned uWSGI worker 3 (pid: 32223, cores: 1)
running "writefifo:./run/running.fifo 2p" (accepting1-once)...
failed to open fifo ./run/running.fifo, -1
open("./run/running.fifo"): No such device or address [core/hooks.c line
127]
running "exec:echo 1 > ./run/new.fifo" (accepting1-once)...
spawned uWSGI worker 4 (pid: 32224, cores: 1)
spawned uWSGI worker 5 (pid: 32226, cores: 1)
spawned uWSGI worker 6 (pid: 32227, cores: 1)
spawned uWSGI worker 7 (pid: 32228, cores: 1)
spawned uWSGI worker 8 (pid: 32229, cores: 1)
opening fifo ./run/new.fifo
managing master fifo on fd 24
Tue Oct 21 23:46:26 2014 - active master fifo is now ./run/running.fifo
managing master fifo on fd 24
managing master fifo on fd 24
opening fifo ./run/running.fifo
--
Stephen Hamer
On Mon, Oct 20, 2014 at 11:44 PM, Roberto De Ioris <[email protected]> wrote:
>
> > 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
>
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
