Ensure you set: LogLevel info
in Apache configuration. Do that and you will likely see that the mod_wsgi daemon process is being restarted because there was no attempt by the application to read input data, our output and response data for a period of 30 seconds. Ie., the application appeared to become inactive. It is 30 seconds because you set inactivity-timeout to be a really low value. So, your application could be doing work that has taken more than 30 seconds to complete, or your application could have deadlocked and go stuck for some reason, although latter not likely as your are using WSGIApplicationGroup to force use of main interpreter. Why are you wanting to run with such a low inactivity timeout? It will kill responsiveness of your application if it doesn't get much traffic as after every restart due to inactivity it has to load the whole of Apache again. Yes you can use inactvity-timeout to drop memory usage, ie., purge application when it isn't doing anything, but 30 seconds is probably too short, as half the time the user wouldn't have even clicked through to next page by then, so will get a slow response on most requests. Ideally, so long as your application is thread safe, you would run with single process and 3-5 threads and a inactivity timeout in minutes and not seconds. Anyway, set LogLevel to info as that will likely give the trigger for daemon processes to be restarted, which in turn is what is causing the Apache child process proxying to that daemon process to output that error when doesn't get a response, not even any headers, within that 30 seconds. Graham On 4 September 2011 20:24, Nick Lo <[email protected]> wrote: > I'm currently looking after a django project running on a Cpanel > server that appears to be building up "Script timed out before > returning headers: index.wsgi" after a few days of running. I'm > monitoring this at the moment to try and find out what may be causing > the issue but since the project is for a time limited event I'm > limited as to what I can dabble with at the moment. The setup is > Apache (as prefork I think)/Nginx proxy with mod_wsgi 3.3 running a > django 1.3 project. Server is also serving PHP sites. Once the > following errors start to build up I've found a restart of Nginx is > all that is needed, so during the event, I'm manually monitoring the > apache error log and if I see these errors I restart Nginx. > > I should mention that I use an .htaccess rewrite rule to redirect to > my index.wsgi in public_html rather than have that set in a vhost.conf > as the latter tends to be a bit obscurely located on Cpanel and, as > you can see, I've been adding eg logging middleware to my index.wsgi > file, etc to try and identify the issues. > > I'd be very appreciative if anyone can let me know of any issues they > can see with any of the following. Clearly I'm no sys-op so am fairly > bumbling my way through/learning on the job with all this. > > Cheers, > > Nick Lo > > ----------------------------------------- > Apache error log: > ----------------------------------------- > > [Sat Sep 03 09:51:25 2011] [error] [client 67.195.114.48] Script timed > out before returning headers: index.wsgi > [Sat Sep 03 09:51:44 2011] [error] [client 95.108.151.244] Script > timed out before returning headers: index.wsgi > [Sat Sep 03 09:51:48 2011] [error] [client 93.158.148.30] Script timed > out before returning headers: index.wsgi > [Sat Sep 03 09:52:02 2011] [error] [client 66.249.72.213] Script timed > out before returning headers: index.wsgi > ----------------------------------------- > > ----------------------------------------- > In: /usr/local/apache/conf/userdata/std/2/<user>/<usersdomain>.org/ > vhost.conf: > ----------------------------------------- > > <IfModule mod_wsgi.c> > # See the link below for an introduction about this mod_wsgi config. > # > http://groups.google.com/group/modwsgi/browse_thread/thread/60cb0ec3041ac1bc/2c547b701c4d74aa > > # WSGIDaemonProcess <user> processes=7 threads=1 display-name=%{GROUP} > WSGIDaemonProcess <user> threads=1 processes=1 stack-size=524288 > display-name=%{GROUP} maximum-requests=500 inactivity-timeout=30 > WSGIProcessGroup <user> > WSGIApplicationGroup %{GLOBAL} > </IfModule> > ----------------------------------------- > > ----------------------------------------- > In public_html/index.wsgi: > ----------------------------------------- > > import os, sys > HOME_DIR = > os.path.dirname(os.path.dirname(os.path.realpath(__file__))) > sys.path.append(HOME_DIR + '/djangoware') > sys.path.append(HOME_DIR + '/djangoware/lib') > > os.environ['DJANGO_SETTINGS_MODULE'] = 'index.settings' > os.environ['PYTHON_EGG_CACHE'] = HOME_DIR + "/djangoware/index/ > cache/" > > import django.core.handlers.wsgi > #application = django.core.handlers.wsgi.WSGIHandler() > > import pprint > > class LoggingMiddleware: > > def __init__(self, application): > self.__application = application > > def __call__(self, environ, start_response): > errors = environ['wsgi.errors'] > pprint.pprint(('REQUEST', environ), stream=errors) > > def _start_response(status, headers, *args): > pprint.pprint(('RESPONSE', status, headers), > stream=errors) > return start_response(status, headers, *args) > > return self.__application(environ, _start_response) > > application = > LoggingMiddleware(django.core.handlers.wsgi.WSGIHandler()) > ----------------------------------------- > > ----------------------------------------- > Nginx.conf: > ----------------------------------------- > > user nobody; > # no need for more workers in the proxy mode > worker_processes 2; > error_log /var/log/nginx/error.log info; > worker_rlimit_nofile 20480; > events { > worker_connections 5120; # increase for busier servers > use epoll; # you should use epoll here for Linux kernels 2.6.x > } > http { > server_name_in_redirect off; > server_names_hash_max_size 10240; > server_names_hash_bucket_size 1024; > include mime.types; > default_type application/octet-stream; > server_tokens off; > sendfile on; > tcp_nopush on; > tcp_nodelay on; > keepalive_timeout 120 120; > proxy_read_timeout 120; > gzip on; > gzip_vary on; > gzip_disable "MSIE [1-6]\."; > gzip_proxied any; > gzip_http_version 1.1; > gzip_min_length 1000; > gzip_comp_level 6; > gzip_buffers 16 8k; > # You can remove image/png image/x-icon image/gif image/jpeg if you > have slow CPU > gzip_types text/plain text/xml text/css application/x-javascript > application/xml image/png image/x-icon image/gif image/jpeg > application/xml+rss text/javascript application/atom+xml; > ignore_invalid_headers on; > client_header_timeout 3m; > client_body_timeout 3m; > send_timeout 3m; > reset_timedout_connection on; > connection_pool_size 256; > client_header_buffer_size 256k; > large_client_header_buffers 4 256k; > client_max_body_size 200M; > client_body_buffer_size 128k; > request_pool_size 32k; > output_buffers 4 32k; > postpone_output 1460; > proxy_temp_path /tmp/nginx_proxy/; > client_body_in_file_only on; > log_format bytes_log "$msec $bytes_sent ."; > include "/etc/nginx/vhosts/*"; > } > ----------------------------------------- > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
