Welcome toVigges Developer Community-Open, Learning,Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.1k views
in Technique[技术] by (71.8m points)

django - Script timed out before returning headers: wsgi.py on elastic beanstalk

I'm trying to deploy a Django application to Elastic Beanstalk. When I visit the page it never loads. The logs say:

Script timed out before returning headers: wsgi.py

I can ssh into the server and run manage.py runserver and then curl 127.0.0.1:8000 from another terminal, which will return the page successfully. So I'm assuming it must be an issue with the Apache configuration that is set up as a part of Elastic Beanstalk.

Here is more of the logs:

[pid 15880] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[so:warn] [pid 15880] AH01574: module wsgi_module is already loaded, skipping
[auth_digest:notice] [pid 15880] AH01757: generating secret for digest authentication ...
[lbmethod_heartbeat:notice] [pid 15880] AH02282: No slotmem from mod_heartmonitor
[mpm_prefork:notice] [pid 15880] AH00163: Apache/2.4.9 (Amazon) mod_wsgi/3.4 Python/2.7.5       configured -- resuming normal operations
[core:notice] [pid 15880] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[:error] [pid 15881] /opt/python/run/venv/lib/python2.7/site-packages/numpy/oldnumeric/__init__.py:11: ModuleDeprecationWarning: The oldnumeric module will be dropped in Numpy 1.9
[:error] [pid 15881]   warnings.warn(_msg, ModuleDeprecationWarning)
[:error] [pid 15881] 
[core:error] [pid 15884] [client 10.248.110.45:58996] Script timed out before returning headers: wsgi.py

And my wsgi.py file:

import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "aurora.settings")

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Any clues as to what could be causing this?

UPDATE:

I rebuilt my environment and ran into this issue again. I updated /etc/httpd/conf.d/wsgi.conf to include WSGIApplicationGroup %{GLOBAL} as mentioned here. I am using Scipy, Numpy, and GeoDjango (which uses GDAL). I know GDAL is not entirely thread safe and I'm not sure about the others but I'm assuming it was a thread safety issue.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

UPDATE 8 FEB 2017

Previously my wsgi.conf was only using one process:

WSGIDaemonProcess wsgi processes=1 threads=15 display-name=%{GROUP}

I upped the processes to something more reasonable and haven't had any issues:

WSGIDaemonProcess wsgi processes=6 threads=15 display-name=%{GROUP}

This change along with the original addition of WSGIApplicationGroup %{GLOBAL} seems to have done the trick.

UPDATE 17 September 2015

I'm still occasionally running in to this issue. Usually, redeploying via eb deploy fixes the issue. It's hard to say what the underlying issue is.

Original Answer

I eventually got the project working but then tried creating an image to use for new instances, which reopened the problem. I'm not sure why it worked then stopped working but I rebuilt my custom AMI from scratch and then repushed my project. Turns out it was an issue in wsgi.py. The version I posted was actually the different from what was being deployed. For some reason another developer had put this in wsgi.py:

path = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
if path not in sys.path:
sys.path.append(path)

I removed this and it fixed the problem.

My advice for anyone having

Script timed out before returning headers: wsgi.py

is to check you wsgi.py file.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to Vigges Developer Community for programmer and developer-Open, Learning and Share
...