I have root access. I did the test, the stuck process died fine with a SIGTERM signal.
>From this I went back to the old mpm_prefork setup that amazon uses, rather than mpm_event, I can't seem to make the issue happen, not sure if really lucky or it is really that. It's a shame if I can't use mpm_event. The issue also happened with mpm_worker. I will need to give it some time of re-deploys to see if the issue still happens. If this is the case, it really seems apache is failing to kill the wsgi process when using mpm_event or mpm_prefork, perhaps something related to the ancient version of mod_wsgi being used. El domingo, 1 de enero de 2017, 19:55:18 (UTC-3), Graham Dumpleton escribió: > > > On 2 Jan 2017, at 9:37 AM, Cristiano Coelho <[email protected] > <javascript:>> wrote: > > I'm not really the one sending the apache restart signals but rather the > amazon environment. Even worse, I can't really restart apache manually > because it won't run the additional amazon commands, which causes a lot of > issues like not setting some environment variables. > > I will give it a shot with info logging to see what's going on. > > > What user account do you have access to the environment as? > > The daemon processes runs as ‘wsgi’ user. You would need to be either > ‘root’ or the ‘wsgi’ user to send the specific daemon process a signal. Not > wanting to send Apache itself a signal, just the one problem process. If it > stops when sent a SIGINT or SIGTERM, then it would indicate issue is more > likely the Apache version or MPM being used. > > Graham > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
