> 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. 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). 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. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
