hi, BranoZ:
Thinks for your nice suggestion, it is very very helpful, and I'm
sorry for the late reply.
with your help I successfully configured zergpool & zerg vassal, and
try to run them with emperor mode. And do as you say, in order to avoid
emperor respawn the old vassal, only delete the ini config.
but it seems the procedure of you deploy is a little complex, wait for
the "ready" file and analysis the uwsgi statistics. Maybe I can write q to
master fifo, and before the instance shutdown, unlink the related ini config
file. It is still gracefull. for example
master-fifo = /tmp/new.fifo
master-fifo = /tmp/running.fifo
if-exists = /tmp/running.fifo
hook-accepting1-once = writefifo:/tmp/running.fifo q
endif =
hook-accepting1-once = writefifo:/tmp/new.fifo 1
hook-as-user-atexit = unlink:/path/%n.ini
I had tested the config, and the behaviour was meeting expectations. but
I'm not sure It is absolutely right, do you have any suggestion?
best regards
At 2016-02-04 00:24:40, "Braňo Žarnovičan" <[email protected]> wrote:
Hi Xin,
I've been struggling with graceful sw deploy for the past week. Although, I
don't consider myself an expert, I might help you by giving you my final
working configs for Zerg and App vassals.
Emperor:
Executed from systemd with single arg
uwsgi --emperor /path/to/vassal/
helloworld_zerg.ini:
[uwsgi]
master = true
zergpool =
/home/foo/var/uwsgi/helloworld.zerg:/home/foo/var/uwsgi/helloworld.sock
helloworld-6bb4c51.ini:
[uwsgi]
chdir = /home/foo/deploy/%n
virtualenv = /home/foo/venv/helloworld
module = helloworld.wsgi
master = true
lazy-apps = false
enable-threads = true
thunder-lock = true
processes = 4
zerg = /home/foo/var/uwsgi/helloworld.zerg
stats = /home/foo/var/uwsgi/%n.stats
vacuum = true
worker-reload-mercy = 600
hook-accepting1-once = write:/home/foo/var/uwsgi/%n.ready ok
hook-as-user-atexit = unlink:/home/foo/var/uwsgi/%n.ready
* there is only one emperor process
* there is one zerg vassal per app
* normally, there is one vassal with N workers per app. During sw deploy, there
may be two App vassals running. Therefor, there is a git hash in vassal's name.
* I had trouble with zerg-pool on uWSGI 2.0.7, so I upgraded to 2.0.12. These
examples were tested on that version.
My deployment of new sw looks like:
1) create new file "vassal/helloworld-<newhash>.ini"
2) wait until "helloworld-<newhash>.ready" file is created
3) connect to "helloworld-<oldhash>.stats" and wait until all workers are in
idle state
4) remove old vassal "vassal/helloworld-<oldhash>.ini"
between steps 2)3), new vassal will start serving requests and old one will
stop. Curiously, no pausing of old vassal was necessary.
Step 3) is necessary, because deleting .ini file in step 4) will trigger
non-graceful shutdown.
On Wed, Feb 3, 2016 at 10:57 AM, xin <[email protected]> wrote:
> If I send a SIGTSTP signal to pause master 1111, the request (curl -s -v
> "http://localhost:9090";) will be suspended, obviously attached zerg
> instance can't work.
You should not touch Zerg vassal (or breathe nearby). No reloads, no pausing..
If I accidentally reload zerg, I have to kill -9 him to recover (emperor will
spawn a new one).
> In doc
> https://uwsgi-docs.readthedocs.org/en/latest/articles/TheArtOfGracefulReloading.html,
> exists the same problem I think. If I shutdown the sleeping instance (
> hook-accepting1-once = writefifo:/var/run/sleeping.fifo Q), the instance
> with zerg server will quit. BTW, I want only one instance exists at the
> same time.
>
> (3)
>
> If use emperor to manage instance, if I spawn a zerg instance and
> graceful shutdown the current instance, emperor always try to respawn the
> main instance, although the zerg instance indeed exists. so how to use
> emperor to finish zero-downtime reload with zerg mode ?
I had the same problem with examples from that document. I recon, they just
give you hints, rather than guiding you by hand with full working examples
(which is a pity).
In emperor mode, you cannot permanently shutdown vassal by sending him "q"/"Q"
to FIFO. Emperor will notice the death of his vassal and respawn it. Vassals in
the "new/running/sleeping" example will simply "dance" ad-infinitum ("sleeping"
with become a "new" one after shutdown and respawn).
The only way I found to permanently shutdown vassal (in emperor mode) was to
delete his .ini file.
Regards,
BranoZ
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
