On Sun, Jan 22, 2012 at 2:56 AM, C Anthony Risinger <[email protected]> wrote: > 2012/1/22 Łukasz Czuja <[email protected]>: >> Hi, >> >> I reported this bug a month or so ago. I have simillar symptomps (saw it >> again couple of days ago): >> >> 2012-19-01 14:12:45 - DAMN ! worker 1 (pid: 3358) died :( trying respawn ... >> 2012-19-01 14:12:45 - Loading paste environment: config:/path/to/paste.ini >> 2012-19-01 14:12:45 - Respawned uWSGI worker 1 (new pid: 3359) >> Traceback (most recent call last): >> (...Error Traceback...) >> 2012-19-01 14:12:46 - SIGINT/SIGQUIT received...killing workers... >> 2012-19-01 14:12:46 - goodbye to uWSGI. >> 2012-19-01 14:12:46 - chdir(): Permission denied [uwsgi.c line 955] >> >> 2012-19-01 14:16:45 - SIGINT/SIGQUIT received...killing workers... >> 2012-19-01 14:16:45 - SIGINT/SIGQUIT received...killing workers... >> 2012-19-01 14:16:45 - SIGINT/SIGQUIT received...killing workers... >> 2012-19-01 14:16:46 - goodbye to uWSGI. >> 2012-19-01 14:16:46 - chdir(): Permission denied [uwsgi.c line 955] >> >> For me the case is: an app started with --paste & 1 master process, 10 >> threads > > oops, i just realized i never finished the subject for this message > ... sorry about that. > > your's definitely looks related, but triggered by another code path. > after attaching a gdb session to both the master and the worker, my > situation seems to be ping-ponging back and forth between the two > processes ... IIRC python is *suppose* to take over the signal for INT > and whatnot during an interactive session (unless specified > otherwise), but what appears to happen is the child process inherits > the old sighandler, and before installing a new one it receives SIGINT > and thus triggers `kill_them_all` *FROM THE WORKER PROCESS*, which > sends a SIGINT signal to ITSELF, which sends a SIGINT signal to itself > ... [repeat 100,000 times] ... the master process is never involved.
so in my case at least, maybe the fix is just to drop all handlers after fork(), before passing control to interactive python ... this way the process just dies if python isn't 100% ready. -- C Anthony _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
