> On 2 Jan 2017, at 4:17 AM, Cristiano Coelho <[email protected]> wrote: > > 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.
Do they at least provide a way of inserting extra configuration inside of the generated VirtualHost definition? If you can’t replace the existing WSGIDaemonProcess definition, then you could create a new WSGIDaemonProcess definition with different name and configuration and then set WSGIProcessGroup to override existing delegation to use it instead. It means there will be a redundant process there, but the WSGI application will never be loaded in it, so memory used would be minimal. > Does this have any default value? No. Off by default. > If this works it might be the best option until the actual issue is actually > found or fixed through an update. As I have said, Amazon is not going to do anything to actively fix this or provide an update. The only way you would get an update is when they shift their Ubuntu version to next LTS Ubuntu release. That may not help though as Debian/Ubuntu is getting so bad with providing an up to date mod_wsgi version there is a chance they still may provide the same old version of mod_wsgi depending on which LTS Ubuntu release they use. Do you know what LTS release they base on now? Since you appear to have some level of root access to install new system packages, the only other option would be to install https-dev. Compile mod_wsgi from source code. Uninstall system mod_wsgi package and then install mod_wsgi module you compiled yourself such that newer mod_wsgi.so is in Apache modules directory at the same location as what there generate Apache configuration looks for it. Even then, if this is due to the Apache version, that is still not going to help. BTW, what Apache and mod_wsgi versions does your development environment use? Graham > 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] > <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.
