On Sun, Jan 22, 2012 at 10:57 AM, Roberto De Ioris <[email protected]> wrote: >> >> An option to stop uwsgi if uWSGI fails to load an app would be useful if >> you consider using uwsgi in system service startup scripts (provided non >> zero exit code is returned by uwsgi). But as for the case I have here, >> uWSGI after receiving SIGQUIT should just kill workers and exit, without >> hogging the system. > > after having audited the code, it looks like a race condition already > fixed in reap_them_all() function months ago, but not in the > kill_them_all() (the one used by signal handling). > > Can you check if it works with the latest tip ? > > In addition to this, failed app loading in lazy mode, will trigger a > different log message.
your change *mostly* works in my case: # ./uwsgi --plugin=python --pyshell --socket @null --master *** Starting uWSGI 1.1-dev-1854 (32bit) on [Sun Jan 22 14:10:03 2012] *** [...] *** Operational MODE: single process *** *** no app loaded. going in full dynamic mode *** *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 30455) spawned uWSGI worker 1 (pid: 30456, cores: 1) >>> DAMN ! worker 1 (pid: 30456) died :( trying respawn ... Respawned uWSGI worker 1 (new pid: 30457) ^CSIGINT/SIGQUIT received...killing workers... SIGINT/SIGQUIT received...killing workers... >>> worker 1 (pid: 30457) is taking too much time to die...NO MERCY !!! goodbye to uWSGI. ... so instead of flooding, it just proceeds normally until timeout, then brutally kills the interpreter process. however, i am now getting a SIGSEGV on normal SIGINT while at the --pyshell prompt: # ./uwsgi --pyshell --socket @null --master *** Starting uWSGI 1.1-dev-1854 (64bit) on [Sun Jan 22 14:08:38 2012] *** [...] *** Operational MODE: single process *** *** no app loaded. going in full dynamic mode *** *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 4283) spawned uWSGI worker 1 (pid: 4284, cores: 1) >>> SIGINT/SIGQUIT received...killing workers... !!! uWSGI process 4284 got Segmentation Fault !!! *** backtrace *** ./uwsgi(uwsgi_backtrace+0x30) [0x42fef0] /lib/libc.so.6(+0x349b0) [0x7f2f5167e9b0] /usr/lib/libpython3.2mu.so.1.0(+0xfdaa0) [0x7f2f51aeaaa0] /usr/lib/libpython3.2mu.so.1.0(PyEval_GetGlobals+0x9) [0x7f2f51ac7629] /usr/lib/libpython3.2mu.so.1.0(PyImport_Import+0x33) [0x7f2f51ae4493] /usr/lib/libpython3.2mu.so.1.0(PyImport_ImportModule+0x1c) [0x7f2f51ae471c] ./uwsgi(get_uwsgi_pydict+0x9) [0x440909] ./uwsgi(uwsgi_python_atexit+0x1e) [0x43ee0e] ./uwsgi(uwsgi_plugins_atexit+0x71) [0x42fa21] /lib/libc.so.6(+0x37481) [0x7f2f51681481] /lib/libc.so.6(+0x37505) [0x7f2f51681505] ./uwsgi() [0x42f9ae] /lib/libpthread.so.0(+0xf8a0) [0x7f2f537ef8a0] /lib/libc.so.6(__select+0x13) [0x7f2f51726963] /usr/lib/python3.2/lib-dynload/readline.cpython-32mu.so(+0x34a0) [0x7f2f4eb974a0] /usr/lib/libpython3.2mu.so.1.0(PyOS_Readline+0x150) [0x7f2f51a3a910] /usr/lib/libpython3.2mu.so.1.0(+0x4e713) [0x7f2f51a3b713] /usr/lib/libpython3.2mu.so.1.0(PyTokenizer_Get+0x58) [0x7f2f51a3c428] /usr/lib/libpython3.2mu.so.1.0(+0x4b1d5) [0x7f2f51a381d5] /usr/lib/libpython3.2mu.so.1.0(PyParser_ASTFromFile+0x99) [0x7f2f51aedc99] /usr/lib/libpython3.2mu.so.1.0(PyRun_InteractiveOneFlags+0x123) [0x7f2f51aeee73] /usr/lib/libpython3.2mu.so.1.0(PyRun_InteractiveLoopFlags+0x4e) [0x7f2f51aef1be] ./uwsgi(uwsgi_python_hijack+0x69) [0x43ed89] ./uwsgi(uwsgi_ignition+0x31) [0x431251] ./uwsgi(uwsgi_start+0x2892) [0x436bd2] ./uwsgi(main+0x1503) [0x413553] /lib/libc.so.6(__libc_start_main+0xed) [0x7f2f5166b38d] ./uwsgi() [0x4136c5] *** end of backtrace *** goodbye to uWSGI. ... this behavior is on x86, x86_64 + python 2.7, 3.2 and ARM (32?) python 2.6, 3.1, with or without --master (child processes is the one segfaulting though). -- C Anthony _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
