> On 1 Jan 2017, at 11:04 AM, Cristiano Coelho <[email protected]> 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
> El sábado, 31 de diciembre de 2016, 20:22:22 (UTC-3), Graham Dumpleton
> escribió:
>
> The mod_wsgi module install using pip is not installed into the Apache
> modules directory, but the Python virtual environment.
>
> We then need to find a way to suppress:
>
> LoadModule wsgi_module modules/mod_wsgi.so
>
> so that isn’t used, and instead use what is output from running:
>
> mod_wsgi-express module-config
>
> A bigger problem is whether mod_wsgi can be installed using pip. If they do
> not include the httpd-dev package on the system, it will not be possible to
> compile any additional Apache modules.
>
> Does the program ‘apxs’ or ‘apxs2’ exist anywhere on the system? Usually it
> would be in /usr/sbin.
>
> 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.
