Hello! On Wed, Feb 28, 2018 at 05:22:14AM -0500, Andrzej Walas wrote:
> Can you answer? The last recommendation you were given is to find out who and why killed nginx worker process, see here: http://mailman.nginx.org/pipermail/nginx/2018-February/055648.html If you think nginx processes are no longer killed, please make sure it is indeed the case: that is, make sure you've stopped nginx (make sure "ps -ef | grep nginx" shows no nginx processes), started it again (record "ps -ef | grep nginx" output here), and you've started to see "ignore long locked" messages after it, and no any critical / alert messages in between. Additionally, compare "ps -ef | grep nginx" output with what you've got right after start - to make sure there are the same worker processes, and no processes were lost or restarted. You may want to share all intermediate results of these steps here for us to make sure you've did it right. If any of these steps indicate that nginx processes are still killed, consider further investigating the reasons. If these steps demonstrate that "ignore long locked" messages appear without any crashes, consider testing various other things to futher isolate the cause. In particular, if you use http2 - try disabling it to see if it helps. If it does, we need debug logs of all requests to a particular resource since nginx start till "ignore long locked" message. Futher information on how to configure debug logging can be found here: http://nginx.org/en/docs/debugging_log.html Note though that enabling debug logging will result in a lot of logs, and obtaining required logs with "inactive" set to 1d might not be trivial as you'll have to store at least the whole day of debug logs till the "ignore long locked" message will appear. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
