That's another good news. Thanks for all the work. BTW, uwsgi master spawns both scripts well if I add two different ones. But the output behaviour is a bit weirdy in the logs. It kind of buffers and doesn't print anything until it kills the one that works with a "while True". But the script actually works quite well over there. It's actually a feature for me but if you still want to look, my ZMQ worker is more less: http://pastebin.com/i3xuyNyQ
On Thu, Jan 16, 2014 at 3:37 PM, Roberto De Ioris <[email protected]> wrote: > > > That's great news. I'm glad that I have contributed somehow. > > > > Unfortunately ns_pid=1 didn't work with the latest github clone. uwsgi is > > running with "uid = 1000" config, which is the owner of runserver.py. > > > > Thu Jan 16 13:15:05 2014 - uwsgi_spawn_daemon()/clone(): Operation not > > permitted [core/daemons.c line 325] > > > Yes namespaces requires privileged access, (you can drop privileges in > daemon with uid and gid options, but i suppose it will make the thing > over-complex). > > Bte in the next few minutes i will push an updated ragnarok procedure, so > the emperor will "gracefully" stop vassals automatically. > > > > > > > > > > > On Thu, Jan 16, 2014 at 1:15 PM, Roberto De Ioris <[email protected]> > > wrote: > > > >> > >> > Well, I am not sending control+c to anyone, if it's working under > >> uwsgi > >> > stack. The code simply listens most of the signals to terminate. And > >> if > >> it > >> > was run from the console, working in the foreground for development > >> > purposes, yes I press control+c to stop in my console. But not when it > >> > gets > >> > executed by another program. http://pastebin.com/TkqBSiyE > >> > > >> > I think I have a clue here. It is about the emperor. See, it seems the > >> > master process is doing quite fine. It is just sending the proper quit > >> > signal to my script when it receives SIGHUP / SIGTERM or SIGINT: > >> > > >> > hu Jan 16 10:38:31 2014 - SIGINT/SIGQUIT received...killing workers... > >> > Thu Jan 16 10:38:31 2014 - [uwsgi-daemons] stopping daemon (pid: > >> 15682): > >> > /path/to/python /path/to/runserver.py > >> > Bye bye! > >> > Bye bye! > >> > Thu Jan 16 10:38:33 2014 - worker 1 buried after 2 seconds > >> > Thu Jan 16 10:38:33 2014 - goodbye to uWSGI. > >> > Thu Jan 16 10:38:33 2014 - VACUUM: unix socket /tmp/app.sock removed. > >> > Thu Jan 16 10:38:36 2014 - *** Starting uWSGI 2.0.1 (64bit) on [Thu > >> Jan > >> 16 > >> > 10:38:36 2014] *** > >> > .... > >> > > >> > I don't understand why do I get the "Bye bye!" message from my script > >> > twice > >> > but perhaps receiving 2 different signals from uwsgi, not that > >> important. > >> > > >> > However, something seems wrong with the emperor. Only SIGHUP signal to > >> > emperor reloads masters gracefully so they kill their attaches too. > >> But > >> > SIGTERM or SIGINT to emperor, kills the masters brutally and > >> immediately. > >> > Therefore there is no master left to send any signal to my script: > >> > > >> > Thu Jan 16 10:50:20 2014 - uWSGI worker 1 screams: UAAAAAAH my master > >> > disconnected: i will kill myself !!! > >> > > >> > So my attached daemons hang on as zombies.. > >> > > >> > > >> > >> Ok, now it is more clear (and somewhat expected) > >> > >> Yes, the "Ragnarok" procedure in the Emperor is pretty brutal, as > >> effectively it simple exit(0) the Emperor (that generally it is not > >> meant > >> to be shutdown). > >> > >> I will improve it for sure (maybe in time for 2.0.1 release) but in the > >> mean time you can add to attach-daemon2 the ns_pid=1 new option (it is > >> on > >> github). It will create the processes in a new namespace, so when the > >> master dies they are completely destroyed. > >> > >> > >> > >> -- > >> 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 > > > > > -- > 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
