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
