> > > W dniu 22.01.2012 11:04, Roberto De Ioris pisze: >>> Yes, also post buffering& harakiri = 300 >>> >> Ok, we must "choose" the way to follow. >> >> In lazy mode we have the ablity to "wait" for an app to be ready. >> >> Your reported behavior is triggered by the worker exiting as the app >> cannot be loaded. The master retry a bit later to respawn it, giving to >> admin/developer the time to fix it. > Current behaviour is working well for the exception of external signal > handling. During this reload if I try to stop uWSGI via SIGQUIT, uWSGI > catches the signal but fills log file with: > > 2012-19-01 14:16:45 - SIGINT/SIGQUIT received...killing workers... > ... > 2012-19-01 14:16:45 - SIGINT/SIGQUIT received...killing workers... > > and hogs the CPU at almost 100%. My guess here is some loop is missing a > sleep() or while(true) is missing a break at some point. It could also > be the case that killing workers is not actually performed for some > reason. > > The "try reload" here is very useful in development. I can quickly fix > an error and the instance is almost instantly working again. >> If you think this is not the expected behaviour, we can think about an >> option to bring down the whole stack on app failed loading. Otherwise i >> think it is sufficient to add another kind of exit code (they are read >> by >> the master to know what to do). > > 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. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
