脚本在返回标头之前超时：弹性 beantalk 上的 wsgi.py答案

【问题标题】：Script timed out before returning headers: wsgi.py on elastic beanstalk脚本在返回标头之前超时：弹性 beantalk 上的 wsgi.py
【发布时间】：2014-10-18 02:14:35
【问题描述】：

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

Script timed out before returning headers: wsgi.py

我可以通过 ssh 进入服务器并从另一个终端运行 manage.py runserver 和 curl 127.0.0.1:8000，这将成功返回页面。所以我假设它一定是作为 Elastic Beanstalk 的一部分设置的 Apache 配置的问题。

这里有更多日志：

[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 不是完全线程安全的，我不确定其他人，但我假设这是一个线程安全问题。

【问题讨论】：

我正在使用 pandas 和 numpy 并遇到了同样的问题。添加 WSGIApplicationGroup %{GLOBAL} 解决了这个问题 - 但是手动编辑文件并不能解决新的 beanstalk 实例。要解决这个问题，请按照this answer 中描述的步骤操作
重启 beanstalk 实例后也一样。

标签： django apache mod-wsgi wsgi amazon-elastic-beanstalk

【解决方案1】：

就像你提到的那样，这确实看起来像是 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

【讨论】：

感谢乔希的回答。 WSGI 位置正确，我已阅读文档。对于更多上下文，我正在使用自定义 AMI，我短暂地让它工作，但随后我立即尝试创建一个图像，这再次破坏了整个事情。我不确定您是否有任何提示，因为您在 EBS 上工作，但是安装任何像 Scipy 和 Numpy 这样不重要的东西是非常痛苦的，因为pip install scipy 需要很长时间并且最终会超时。但是使用所有 pip 包烘焙自定义 AMI 似乎也是不可能的。
我很高兴你能弄明白。干杯。
感谢您的关注。确认这是一个 Apache/WSGI 问题帮助我集中精力。最好。

【解决方案2】：

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 文件。

【讨论】：

你还在面对这个问题吗？我在 eb 上部署了两个应用程序。其中一个运行良好，而另一个（我正在使用 scipy）面临这个问题。
wsgi.py 驻留在哪里？
我可以确认这个问题与在最新版本的pip 上安装numpy 和Python 科学堆栈的许多其他元素有关。在旧 Django 服务器上升级 numpy 后，我曾多次遇到它。

【解决方案3】：

在我遇到的类似问题上只需我的 2 美分。

我遇到了类似的问题。事实证明，从 django 应用程序执行的脚本（进行 DB 插入/更新/删除调用）正处于死锁状态等待释放表上的锁。发布后，代码通过而没有此错误。我无需重新部署我的 EB 应用程序。

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

【讨论】：

【解决方案4】：

我们的解决方法是按照Meistro's answer 添加WSGIApplicationGroup %{GLOBAL} 设置。

您需要确保通过您的.ebextensions/foobar.config 文件编辑您的wsgi 配置，以便更改是永久性的。 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}

这将使用WSGIApplicationGroup %{GLOBAL} 创建（或覆盖）/etc/httpd/conf.d/wsgi_custom.conf 文件的内容

【讨论】：

【解决方案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(my case) 模块更改了默认加载模式。

找到下面的位置

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

根据我们的情况启用工作模块

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

再次感谢帮助我的人。

【讨论】：

【解决方案6】：

我遇到了这个问题，直到我意识到我使用的是不同的 Python 版本。让我解释一下。我使用的是 CentOS 7。CentOS 7 中的默认 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 包。

最好的问候！

【讨论】：