I would suggest trying to use:

    
http://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#tracking-request-and-response
 
<http://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#tracking-request-and-response>
    
http://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#extracting-python-stack-traces
 
<http://modwsgi.readthedocs.io/en/develop/user-guides/debugging-techniques.html#extracting-python-stack-traces>

to get more information out about what the WSGI application does respond with 
and where it may be getting stuck.

Further comments below.

> On 5 Feb 2018, at 4:43 am, Thomas <ktlomb...@gmail.com> wrote:
> 
> Hi there,
> 
> I'm hoping someone can help me out here :-)
> 
> Problem description:
> - When setting the Django settings option "DEBUG = False" (typically used to 
> switch to production settings) I get a "Gateway Timeout" from Apache. When 
> "DEBUG = True" everything works just fine!
> - Apache error: mod_wsgi Timeout when reading response headers from daemon 
> process.

After how long waiting?

> 
> Setup:
> - I have a vanilla install of Ubuntu16.04 with Apache 2.4. As per the 
> "mod_wsgi" documentation I am making use of the virtual environment to load 
> up the "mod_wsgi" environment into Apache.
> - I have a Python virtual environment running where all of my required Python 
> libraries / modules are located (including "mod_wsgi"). All Python libraries 
> / modules are at the latest stable versions.
> - I have only used the default package managers i.e.: apt and pipenv 
> respectively on this clean install.
> - The Apache user / group "www-data" is the owner of the default "/var/www/" 
> directory.
> 
> Apache virtual host configuration:
> """
> <VirtualHost *:80>
>     ServerName www.blah.com
>     ServerAlias blah.com
>     RewriteEngine On
>     RewriteCond %{HTTP:X-Forwarded-Proto} !https
>     RewriteRule . https://www.blah.com%{REQUEST_URI} [L,R=permanent]
> </VirtualHost>
> 
> <VirtualHost *:443>
>     ServerName www.blah.com
>     ServerAlias blah.com
> 
>     SSLEngine on
>     SSLCertificateFile /var/www/.ssl/blah.com.pem
>     SSLCertificateKeyFile /var/www/.ssl/blah.com.key
> 
>     LogLevel info
>     ErrorLog /var/www/logs/error-blah.log
>     CustomLog /var/www/logs/access-blah.log combined
> 
>     DocumentRoot /var/www/blah.com <http://blah.com/>
As best security practice, you should not set DocumentRoot to be a parent 
directory of your source code. If you were to comment out the WSGIScriptAlias, 
people could download your application code. Leave it out so defaults to server 
wide document root, or point it at an empty directory.

> 
>     Alias /static 
> /var/www/.virtualenvs/www-elNfpBxP/lib/python3.5/site-packages/django/contrib/admin/static/
> 
>     <Directory /var/www/blah.com>
>         Require all granted
>     </Directory>
> 
>     WSGIDaemonProcess blah processes=5 inactivity-timeout=300 
> display-name=%{GROUP} python-home=/var/www/.virtualenvs/www-elNfpBxP/ 
> python-path=/var/www/blah.com/ <http://blah.com/>
Avoid using inactivity-timeout. Look at using request-timeout instead. See:

    
http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html
 
<http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html>

including section at end about good overall defaults.

>     WSGIProcessGroup blah
>     WSGIApplicationGroup %{GLOBAL}

You don't need WSGIProcessGroup and WSGIApplicationGroup since you set those as 
arguments to WSGIScriptAlias.

>     WSGIScriptAlias / /var/www/blah.com/etc/wsgi/production_platform.py 
> process-group=blah application-group=%{GLOBAL}
>     WSGIPassAuthorization On
> </VirtualHost>
> 
> LoadModule wsgi_module 
> /var/www/.virtualenvs/www-elNfpBxP/lib/python3.5/site-packages/mod_wsgi/server/mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so
> WSGIRestrictEmbedded On

I presume the LoadModule isn't actually at the end. It should be very first 
thing Apache sees related to mod_wsgi.

If it isn't, you may have a different mod_wsgi being loaded.

> WSGILazyInitialization On

You don't need WSGILazyInitialization as that is the default.

> """
> 
> Apache configuration output:
> """
> $ apachectl -V
> 
> Server version: Apache/2.4.18 (Ubuntu)
> Server built:   2017-09-18T15:09:02
> Server's Module Magic Number: 20120211:52
> Server loaded:  APR 1.5.2, APR-UTIL 1.5.4
> Compiled using: APR 1.5.2, APR-UTIL 1.5.4
> Architecture:   64-bit
> Server MPM:     event
>   threaded:     yes (fixed thread count)
>     forked:     yes (variable process count)
> Server compiled with....
>  -D APR_HAS_SENDFILE
>  -D APR_HAS_MMAP
>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>  -D APR_USE_SYSVSEM_SERIALIZE
>  -D APR_USE_PTHREAD_SERIALIZE
>  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>  -D APR_HAS_OTHER_CHILD
>  -D AP_HAVE_RELIABLE_PIPED_LOGS
>  -D DYNAMIC_MODULE_LIMIT=256
>  -D HTTPD_ROOT="/etc/apache2"
>  -D SUEXEC_BIN="/usr/lib/apache2/suexec"
>  -D DEFAULT_PIDLOG="/var/run/apache2.pid"
>  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
>  -D DEFAULT_ERRORLOG="logs/error_log"
>  -D AP_TYPES_CONFIG_FILE="mime.types"
>  -D SERVER_CONFIG_FILE="apache2.conf"
> 
> $ apachectl -M
> 
> Loaded Modules:
>  core_module (static)
>  so_module (static)
>  watchdog_module (static)
>  http_module (static)
>  log_config_module (static)
>  logio_module (static)
>  version_module (static)
>  unixd_module (static)
>  access_compat_module (shared)
>  alias_module (shared)
>  auth_basic_module (shared)
>  authn_core_module (shared)
>  authn_file_module (shared)
>  authz_core_module (shared)
>  authz_host_module (shared)
>  authz_user_module (shared)
>  autoindex_module (shared)
>  deflate_module (shared)
>  dir_module (shared)
>  env_module (shared)
>  filter_module (shared)
>  mime_module (shared)
>  mpm_event_module (shared)
>  negotiation_module (shared)
>  rewrite_module (shared)
>  setenvif_module (shared)
>  socache_shmcb_module (shared)
>  ssl_module (shared)
>  status_module (shared)
>  wsgi_module (shared)
> 
> $ ~/.virtualenvs/www-elNfpBxP/lib/python3.5/site-packages/mod_wsgi/server$ 
> ldd mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so
> 
> linux-vdso.so.1 =>  (0x00007fffa35db000)
> libpython3.5m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 
> (0x00007fd6159e1000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd6157c4000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd6153fa000)
> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fd6151d1000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd614fb7000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd614db3000)
> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fd614bb0000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd6148a7000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fd6162a3000)
> """
> 
> Any ideas as to how I can isolate the what is causing the problem or point me 
> in the right direction before I go down the proverbial rabbit hole?
> 
> Thanks in advance.
> Thomas
> 
> 
> -- 
> 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 modwsgi+unsubscr...@googlegroups.com 
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To post to this group, send email to modwsgi@googlegroups.com 
> <mailto:modwsgi@googlegroups.com>.
> 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 modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to