Question

我正在尝试将Django应用程序部署到Elastic Beanstalk。当我访问页面时，它永远不会加载。日志说：

Script timed out before returning headers: wsgi.py

我可以直接进入服务器并从另一个终端运行manage.py runserver然后curl 127.0.0.1:8000，这将成功返回页面。所以我认为它必须是Apache配置的一个问题，它是作为Elastic Beanstalk的一部分设置的。

以下是更多日志：

[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

我的wsgi.py文件：

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

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

有关可能导致此问题的任何线索？

更新：

我重建了我的环境并再次遇到了这个问题。我更新了/etc/httpd/conf.d/wsgi.conf以包含WSGIApplicationGroup %{GLOBAL} as mentioned here。我使用的是Scipy，Numpy和GeoDjango（使用GDAL）。我知道GDAL不是完全线程安全的，我不确定其他的，但我认为这是一个线程安全问题。

Answer 1

2017年2月8日更新

以前我的wsgi.conf只使用一个流程：

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

我将流程提升到更合理的水平并且没有任何问题：

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

此更改以及WSGIApplicationGroup %{GLOBAL}的原始添加似乎已成功。

2015年9月17日更新

我仍然偶尔会遇到这个问题。通常，通过eb deploy重新部署可以解决问题。很难说基本问题是什么。

原始答案

我最终让项目工作，但后来尝试创建一个用于新实例的图像，这又重新解决了问题。我不确定为什么它工作然后停止工作但我从头开始重建我的自定义AMI然后重新推出我的项目。原来这是wsgi.py中的一个问题。我发布的版本实际上与部署的版本不同。出于某种原因，另一位开发人员将其放在wsgi.py：

中

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

我删除了它并修复了问题。

我对任何人的建议

Script timed out before returning headers: wsgi.py

是检查wsgi.py文件。

Answer 2

看起来像你提到的WSGI和Apache似乎是一个问题。要仔细检查的一件事是源目录中的.ebextensions文件。

应该有一个配置，指定WSGI信息，如应用程序的位置。您可能还想检查Django设置并使用WSGI在Apache本地设置本地运行。

您可能已经阅读过WSGI和Django的官方文档，但这可能会抓住您可能错过的一些简单的事情：http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_django.html#create_deploy_Python_django_update

Answer 3

就我遇到的类似问题而言，只需2美分。

我有类似的问题。事实证明，从django应用程序执行的脚本（进行数据库插入/更新/删除调用）正在等待处于死锁状态，以便释放表上的锁。一旦它被释放，代码就会没有这个错误。我从来没有必要重新部署我的EB应用程序。

确保您没有通过任何其他SQL客户端连接到数据库。如果是，请查询任何活动锁。（在我的例子中，我正在连接到redshift。查询STV_LOCKS表列出了活动锁）。
检查谁持有锁。（在我的例子中，它是我的SQL客户端，连接到redshift，它执行了一个CUD操作，并且由于没有发出COMMIT，它在表上持有挂起的写锁定。）
我从我的SQL客户端发出了一个提交，锁被释放了。我的EB代码已经完成，并且不再有脚本超时错误。

Answer 4

我们的修复是根据Meistro's answer添加WSGIApplicationGroup %{GLOBAL}设置。

您需要确保通过wsgi文件编辑.ebextensions/foobar.config配置，以便更改是永久性的。 See the .ebextensions config docs

将以下内容添加到.ebextensions/foobar.config文件中：

files:
  "/etc/httpd/conf.d/wsgi_custom.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      WSGIApplicationGroup %{GLOBAL}

这将使用/etc/httpd/conf.d/wsgi_custom.conf

创建（或覆盖）WSGIApplicationGroup %{GLOBAL}文件的内容

Answer 5

我已经尝试过以上可以暂时解决问题的步骤。然后我做了以下步骤：

在“.ebextensions”文件夹下输入“packages.config”文件并放入以下行

WSGIApplicationGroup: command: grep -rnw 'WSGIApplicationGroup' config.py || sed -i.bak '/LogFormat/ a WSGIApplicationGroup %%{GLOBAL}' config.py cwd: /opt/elasticbeanstalk/hooks

感谢帮助让这个人给出了这类错误的建议

我终于修好了。刚刚阅读了关于apache mpm加载模块的概念

我从apache preforker（我的情况）模块更改了默认加载模式，这取决于操作系统。

找到以下位置

位置：/etc/httpd/conf.module.d/00-mpm*.

启用依赖于我们案例的工人模块

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

Answer 6

我遇到了这个问题，直到意识到自己使用的是其他Python版本。让我解释一下。我使用的是CentOS7。CentOS7中的默认Python版本是Python 2.7，但是我的代码使用Python 3.6，因此我通过执行以下操作在同一台计算机上安装了Python 3.6：

sudo yum install centos-release-scl
sudo yum install rh-python36 rh-python36-python-pip rh-python36-python-virtualenv
scl enable rh-python36 bash

然后创建一个虚拟环境并在WSGI中使用它：

    WSGIScriptAlias   / /var/www/myproject/myproject/wsgi.py
    WSGIDaemonProcess myproject python-home=/var/www/myproject python-path=/var/www/myproject:/var/www/myproject/lib/python3.6/site-packages
    WSGIProcessGroup  myproject

出现“脚本超时”问题。然后我意识到mod_wsgi.so是针对libpython2.7.so.1.0编译的。

# ldd /usr/lib64/httpd/modules/mod_wsgi.so
linux-vdso.so.1 =>  (0x00007ffd3fcae000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f1240cd4000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1240ab8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f12408b3000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f12406b0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f12403ae000)
libc.so.6 => /lib64/libc.so.6 (0x00007f123ffe0000)
/lib64/ld-linux-x86-64.so.2 (0x00005598a5aac000)

解决方案是删除mod_wsgi软件包并安装rh-python36-mod_wsgi软件包。

最诚挚的问候！

脚本在返回标题之前超时：弹性beanstalk上的wsgi.py

6 个答案: