It seems I'm unable to modify any other param of the WSGIDaemonProcess directive, at least not by normal means through their config file, maybe through some hackish way like overwriting the whole wsgi file or attempting to change that exact line through a linux command. Does this have any default value? If this works it might be the best option until the actual issue is actually found or fixed through an update.
All threads are started as dameon, and looking at the multiprocessing.pool.ThreadPool code its internal threads are also started as daemon so there's no way they are locking the process. This really is something related to either apache or mod_wsgi since there's no way to reproduce the issue locally, such as doing tests with threads and pools and attempting to block the process. I will set up the info logging level of apache and play around to see if I can find something else. El sábado, 31 de diciembre de 2016, 22:12:51 (UTC-3), Graham Dumpleton escribió: > > > On 1 Jan 2017, at 11:04 AM, Cristiano Coelho <[email protected] > <javascript:>> wrote: > > "LoadModule wsgi_module modules/mod_wsgi.so" is written in two files > created by amazon, conf.d/wsgi.conf and conf.modules.d/wsgi.conf (why it > is twice is beyond me) so I need to delete one and overwrite the other to > not include this line but define all the apache/mod_wsgi settings such as > virtual host and stuff which might be quite painful since that file is > created automatically by amazon and also uses deployment metadata for some > values/paths so it probably gets overwritten every time. > > httpd-dev package can probably be installed if it can be installed through > "yum install xxx" since a few other packages are installed that way through > the deployment file (such as postgres devel) > > apxs or apxs2 are not there, only apachectl. > > So I guess it would really be too much effort to try to use a different > mod_wsgi version, and it's probably better to simply wait for amazon to > release a new version of the linux machine for that. > > > From what I understand they do not update their machine images very often. > They are also unlikely to upgrade to newer versions of anything, just patch > security issues. > > The logs doesn't ring any bell? *It almost seems that it is the apache > process that is actually stuck and is being shut down improperly, which is > causing mod_wsgi processes that rely on it to not be shut down, can that be > possible?* > > > Shouldn’t be the case. > > I'm really suspecting about apache mpm_event maybe having some issues, > considering this happens way more frequently on production with a load > balancer (its an aws load balancer which basically keeps long lived > connections to apache) compared to dev that rarely happens but browsers hit > apache directly, and other projects that use defult aws apache config ( > mpm_prefork, ugh) doesn't seem to have this issue, but mpm_prefork is so > bad with its multiple processes per request eating a lot of memory that > probably means bigger machines to handle the same amount of traffic, reason > mpm_event is used. > > I'm unware of python2.7 daemon threads, or multiprocessing.pool.ThreadPool > having issues with keeping processes alive. > > > Two things to look at. > > 1. Since you are creating background threads to do work, ensure that when > you create them they are being marked as daemon threads. Eg: > > self.monitor_thread = threading.Thread(target=self.monitor) > self.monitor_thread.setDaemon(True) > self.monitor_thread.start() > > There is a fail safe in mod_wsgi to guard against problems caused by this > not being done, in that if Python interpreter destruction hangs on process > shutdown, the process should be forcibly killed off. Best still to ensure > you are doing it. > > 2. If you are able to modify what options are supplied to > WSGIDaemonProcess directive, add the option: > > inactivity-timeout=60 > > If the process gets orphaned and is not accepting requests, thus is idle, > this should result in process being forcibly shutdown after 60 seconds. > > Just be aware that if the traffic of your web application is so light that > it goes for periods of a minute when no traffic, the process will be > restarted in that case as well. Generally this shouldn’t be an issue > though, except for one special case in the old version of mod_wsgi you > have. If you have long running requests and all requests threads block for > 60 seconds with no data in or out, process will be restarted then as well. > > 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.
