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. yours is maybe related, where the worker is inheriting the masters handler, or ... -- C Anthony _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
