> On 2 Jan 2017, at 9:37 AM, Cristiano Coelho <[email protected]> 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 > El domingo, 1 de enero de 2017, 19:01:44 (UTC-3), Graham Dumpleton escribió: > >> On 2 Jan 2017, at 8:58 AM, Cristiano Coelho <[email protected] <>> wrote: >> >> Nope. You wouldn’t be overriding the wsgi.conf file, but adding a new conf >> file in same directory. Apache will load files when using Include with >> wildcard in alphabetical order. You can therefore name the file such that is >> ordered before wsgi.conf. It will load that first. You can then rely on fact >> that Apache will use the first VirtualHost it finds when name based virtual >> hosts aren’t actually being used, which is the case here as the generated >> VirtualHost lacks a ServerName directive. You can therefore provide your own >> separate VirtualHost set up how you need it. >> >> This is a good advice, it would certainly allow me to add the timeout >> setting and any other setting I could need for the WSGIDaemonProcess >> directive. The only issue is that I need to match the exact settings and >> file paths the amazon file uses, and if they change it for some reason >> everything would stop working from one day to another, but I guess they >> shouldn't change it at all unless the machine version is updated. >> I will keep this idea as a last resource if I'm not able to find out the >> exact cause of the process not being killed. I still have a few things to >> test before giving up on finding the exact cause. >> > > For these process which you believe hang around, if you send them a SIGTERM > or SIGHUP signal rather than doing a full Apache restart, do they go away? > Best if can get LogLevel set at info when you test that as then mod_wsgi will > log about what it is doing. > >> Which of those two directories is wsgi.conf in? >> What else is in those two directories? >> >> wsgi.conf is at conf.d, at least the one with the virtual host and all >> wsgi.conf setup >> There's also another wsgi.conf at conf.modules.d but all it does is load the >> wsgi module. > > The one in conf.modules.d is added when you install the system mod_wsgi > package. > > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
