web-dev-qa-db-ja.com

WSGI：デーモンプロセスから受信した応答ヘッダーが切り捨てられているか、サイズが大きすぎます

システム構成：Apache2、Django 1.10、Python 3、Ubuntu 16.04 LTS

Django debug=True。

/ var/log/Apache2/error.log

[52:53.057967] [wsgi:error] [pid 4303] [client 1.1.1.22:24409] Timeout when reading response headers from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466726] [wsgi:error] [pid 4305] [client 1.1.1.10:9787] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466729] [wsgi:error] [pid 4304] [client 1.1.1.4:18417] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466726] [wsgi:error] [pid 4307] [client 1.1.1.22:35116] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.466756] [wsgi:error] [pid 4306] [client 1.1.1.22:19242] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.467164] [wsgi:error] [pid 4336] [client 1.1.1.4:34187] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.467212] [wsgi:error] [pid 4342] [client 1.1.1.22:28212] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py, referer: http://example.org/
[52:58.467282] [wsgi:error] [pid 4331] [client 1.1.1.22:31045] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py
[52:58.467426] [wsgi:error] [pid 4341] [client 1.1.1.70:22784] Truncated or oversized response headers received from daemon process 'example.org': /home/user/dir/project/main_app/wsgi.py, referer: http://example.org/

エラーの原因はわかりません。しかし、Django wsgiプロセスに絞り込んでいます。サーバーが静的ファイルを適切にホストしているためです。

Cloudflareは502：Bad Gateway Errorを表示することがありますが、サーバー自体は500：内部サーバーエラーを表示します。

私はすでにサーバーを再起動し、Django（デバッグ）ログファイルを確認しようとしました。 Djangoログファイル（すべて）にはエラー情報がありません。

問題をデバッグするにはどうすればよいですか？ Djangoは何も記録しなかったので、問題はwsgiで引き起こされる可能性があると思います。

注：サーバーは以前は正常に動作していました。私はいくつかの変更を加えました*（これは元の状態に戻されます）。 Djangoシェルは正常に動作します。

変更*

  1. インストールされたDjango-pandas、Django-model-utils、numpy、scikit-learn
  2. 上記のライブラリを利用するプログラム。 （この変更は元に戻されます）

他の同様の質問では、大きなファイルのアップロード中に問題が発生します。

djangomod-wsgiapache2
10
Suraj

問題の原因はnumpyでした。

NumpyなどのPython C拡張モジュールは、mod_wsgiで使用するとタイムアウトを引き起こすことが知られています。

出典： Sean F で回答 デーモンプロセスから応答ヘッダーを読み取るときにタイムアウト

私が最初の検索で見つけなかった同様の質問は、mod_wsgiの作者によって回答され、説明されています-

C拡張モジュールを使用するPythonのサードパーティパッケージには、scipyとnumpyが含まれ、Pythonメインインタープリタでのみ機能し、デフォルトではmod_wsgiとしてのサブインタープリターが使用され、その結果、スレッドのデッドロック、不正な動作、またはプロセスのクラッシュが発生する可能性があります。

出典： Graham Dumpleton で回答 scipyをインストールした後の非応答Apache + mod_wsgi

解決

以下の行をhttpd.confに追加します。私の場合、ファイルは/etc/Apache2/Apache2.confでした。

WSGIApplicationGroup %{GLOBAL}
8
Suraj

他の人が述べたように、これはいくつかの潜在的な理由でプロセスがクラッシュしたことが原因です。 1つの理由は、一部のPython=依存関係がスレッドセーフではないことです。

それが問題である場合、回避策の1つは、ApacheのMPMタイプを切り替えることです。 preforkタイプはスレッドを使用しないため、問題がスレッドの誤用による派手なクラッシュである場合は、それで修正されます。ワーカータイプとイベントタイプではメモリの使用量は少なくなりますが、スレッドも使用するため、このエラーが発生する可能性があります。

現在使用しているタイプを確認するには、次のコマンドを実行します。

apachectl -V | grep -i mpm

Server MPM: preforkが表示されている場合は、すでにpreforkを使用しているため、エラーの原因が別の原因である可能性があります。 「worker」または「event」と表示されている場合は、次のコマンドを実行してpreforkに切り替えることができます。

Sudo a2dismod mpm_event
Sudo a2dismod mpm_worker
Sudo a2enmod mpm_prefork
Sudo service Apache2 restart

Preforkの主な欠点は、スレッドを使用していないため、より多くのメモリを消費することです。

編集：他の原因でこのエラーが発生しました。最近の問題は、Ubuntuのプリコンパイルされたmod-wsgiシステムパッケージのバグと、Python psycopg2パッケージのバグが原因です。

この解決策は、システムのmod-wsgiからPythonパッケージに切り替えることと、psycopg2-binaryパッケージに切り替えることです。

Sudo apt purge libapache2-mod-wsgi*
Sudo apt install Apache2-dev
pip uninstall psycopg2
pip install mod_wsgi psycopg2-binary

また、トップに追加して、Apacheサイト構成ファイルを更新する必要がありました。

LoadModule wsgi_module /usr/local/myproject/.env/lib/python2.7/site-packages/mod_wsgi/server/mod_wsgi-py27.so

そして、私のWSGIDaemonProcessステートメントを、python-pathではなくpython-homeを使用するように変更します。

WSGIDaemonProcess myproject python-home=/usr/local/myproject/.env processes=5 threads=15 display-name=%{GROUP} user=www-data group=www-data

Python2.7とPython3.7の両方でこれに遭遇しましたが、解決策は同じですが、mod_wsgi.soへのパスが変更されています。

6
Cerin

Mod_wsgiとApacheを使用してopencvを実行しようとすると、同様のエラーを受け取りました。問題はおそらく、基になるCコードがGILを取得しようとして失敗した複数のスレッドにあったと思います。

WSGIDaemonProcessディレクティブでthreads = 1およびprocesses = 32（私の場合はそれが適切であった）を設定することで解決しました。

PS：パーティーに遅れましたが、誰かを助けることができると思いました。

2
mind_stone

Python access to magic（libmagic）から取得しました。magicの一部のバージョンはそのように動作します。バージョンをコンパイルして、それを解決した何らかの理由で、OSに付属するものの代わりにそれを使用しました。

0
Amichai Schreiber

私の場合、WSGIDaemonProcess行を次のように変更する必要がありました。

WSGIDaemonProcess wsgi processes=2 threads=4 display-name=%{GROUP} \
  python-path=/var/www/appname:/var/www/appname/venv/lib/python2.7/site-packages user=wsgi group=wsgi \
  home=/var/www/appname

に：

WSGIDaemonProcess appname user=wsgi group=wsgi processes=2 threads=4 display-name=%{GROUP} home=/var/www/appname
0
RyanH

私の場合、問題はpymongoとPHPでした。このGitHubの問題で説明されているように https://github.com/GrahamDumpleton/mod_wsgi/issues/351 ：

PHPがMongoDBのクライアントをロードしている場合、[競合を作成する]ことができます。（...）PHPは多くの場合、すべての拡張機能をプリロードします。ホストされたアプリケーションがそれを使用するかどうか。

私がそれを解決した方法：

  1. flask app from mod_wsgi-express：mod_wsgi-express start-server api.wsgi --user=www-data --group=www-data --Host=0.0.0.0 --port=8443。
  2. 次に、私のhttpd.conf、すべてのトラフィックを次の方法でmy flask app aliasにリダイレクトしました。
SSLEngine on
SSLProxyEngine On
ProxyPass /api http://localhost:8443/
ProxyPassReverse /api http://localhost:8443/
0
prm296