web-dev-qa-db-ja.com

ヘッダーを返す前にスクリプトがタイムアウトしました：Elastic Beanstalkのwsgi.py

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}ここで述べたように 。私はScipy、Numpy、およびGeoDjango（GDALを使用）を使用しています。 GDALは完全にスレッドセーフではないことを知っています。他のスレッドについてはよくわかりませんが、スレッドセーフの問題であると思います。

djangoapachemod-wsgiwsgiamazon-elastic-beanstalk
21
Meistro

2017年2月8日更新

以前、私のwsgi.confは1つのプロセスしか使用していませんでした：

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ファイルを確認します。

13
Meistro

私たちのための修正は Meistroの答え に従ってWSGIApplicationGroup %{GLOBAL}設定を追加することでした。

.ebextensions/foobar.configファイルを使用してwsgi構成を編集し、変更が永続的になるようにする必要があります。 。ebextensions構成ドキュメントを参照 。

以下を.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}で作成（または上書き）されます

4
Chris W.

私が直面した同様の問題についてちょうど2セント。

同様の問題がありました。 Django=アプリケーションから実行されているスクリプト（DB挿入/更新/削除呼び出しを行う）がデッドロック状態でテーブルのロックが解放されるのを待っていたことがわかりました。コードがリリースされると、コードはこのエラーなしで通過し、EBアプリケーションを再デプロイする必要がなくなりました。

  1. 他のSQLクライアントを介してデータベースに接続していないことを確認してください。はいの場合、アクティブなロックを照会します。 （私の場合、redshiftに接続していました。STV_LOCKSテーブルを照会すると、アクティブなロックがリストされます）。
  2. ロックを保持しているユーザーを確認してください。 （私の場合、CUD操作を実行したのはredshiftに接続されたSQLクライアントであり、COMMITが発行されなかったため、テーブルに保留中の書き込みロックを保持していました）。
  3. SQLクライアントからコミットを発行し、ロックが解除されました。私のEBコードは通過し、スクリプトのタイムアウトエラーはもう発生しませんでした。
4
Kris

あなたが言ったように、それは確かに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

4
Josh Davis

一時的に問題を解決できる上記の手順を試しました。次に、次の手順を実行しました。

  1. 「.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ロードモジュールのコンセプトについて読む

Osに依存するApache preforker（my case）モジュールからデフォルトのロードモードが変更されました。

場所の下で見つける

場所：/etc/httpd/conf.module.d/00-mpm*.

ケースに依存するワーカーモジュールを有効にする

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

もう一度私を助けてくれた人に感謝します。

0
selvasundarraj

別のPython=バージョンを使用していることに気付きました。これについて説明させてください。CentOS7を使用していました。デフォルトのPythonバージョンCentOS 7では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パッケージをインストールすることでした。

宜しくお願いします！

0
Bstia