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.
Please take a look at Anthony's messages. He tried stracing this error.
We currently have:
1 -> worst thing in the world happened (trigger reload with evil message
in the logs)
17 -> reload the process (trigger reload reporting the not-critical status
in the logs)
30 -> end the process (leave the process off)
26 -> exile the process (use by the emperor for bad behaving instances)
We can have a generic "reload later" condition, or a "app loading failed"
where the admin will chose (via config options) what to do when this happens.
--
Pozdrawiam,
Łukasz Czuja
Programista / Analityk / Architekt IT
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
