0

fastcgi を使用して apache で実行されている django アプリがあります (Flup の WSGIServer を使用します)。

これは、dispatch.fcgi を介してセットアップされ、以下に連結されます。

#!/usr/bin/python

import sys, os

sys.path.insert(0, os.path.realpath('/usr/local/django_src/django'))

PROJECT_PATH=os.environ['PROJECT_PATH']

sys.path.insert(0, PROJECT_PATH)

os.chdir(PROJECT_PATH)

os.environ['DJANGO_SETTINGS_MODULE'] = "settings"

from django.core.servers.fastcgi import runfastcgi

runfastcgi(method="threaded",daemonize='false',)

runfastcgi は作業を行うものであり、最終的に WSGIHandler で WSGIServer を実行します。

fastcgi をクラッシュさせる例外が発生することがあります。

編集: どのエラーが fastcgi をクラッシュさせるか、または fastcgi がクラッシュするかどうかはわかりません。Apacheを再起動するまで、サイトがダウンすることがあることを知っています-一貫してダウン--。error.log に表示される唯一のエラーは、以下に示す壊れたパイプと不完全なヘッダーのものです。

不完全なヘッダー:

注: 機密情報や雑然としたものは "..." に置き換えました

[Sat May 09 ...] [error] [client ...] (104)Connection reset by peer: FastCGI: comm with server ".../dispatch.fcgi" aborted: read failed
[Sat May 09 ...] [error] [client ...] FastCGI: incomplete headers (0 bytes) received from server ".../dispatch.fcgi"
[Sat May 09 ...] [error] [client ...] (32)Broken pipe: FastCGI: comm with server ".../dispatch.fcgi" aborted: write failed,

壊れたパイプ:

注: これはたまたま django アプリではなく trac サイト用ですが、見た目は同じです。

Unhandled exception in thread started by <bound method Connection.run of <trac.web._fcgi.Connection object at 0xb53d7c0c>>
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 654, in run
    self.process_input()
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 690, in process_input
    self._do_params(rec)
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 789, in _do_params
    self._start_request(req)
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 773, in _start_request
    req.run()
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 582, in run
    self._flush()
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 589, in _flush
    self.stdout.close()
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 348, in close
    self._conn.writeRecord(rec)
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 705, in writeRecord
    rec.write(self._sock)
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 542, in write
    self._sendall(sock, header)
  File "/usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 520, in _sendall
    sent = sock.send(data)
socket.error: (32, 'Broken pipe')

/var/log/apache2/error.log を調べましたが、クラッシュの原因がわかりません。メモリのスワップの問題が時々発生しますが、これは違うと思います。(私の無知を許してください。私は、サーバー管理をより適切に実装およびデバッグする方法を学びたいと思っています。)

runfastcgi を try/except でラップしたいと思います。ランダムな例外を処理する最良の方法は何ですか (実際の原因を突き止めるまで)?

WSGIServer は多くのリクエストを処理すると思います。例外をキャッチした場合、無限ループを恐れずに runfastcgi を再呼び出しできますか? 問題のある例外呼び出し要求に対してエラー HttpRequest を返す必要がありますか? 私はそれを行う方法さえわかりません。

私はdjango/core/servers/fastcgi.pyとdjango/core/handlers/wsgi.pyとdjango/http/init.pyを見てきました

flup の側面について理解を深めることができませんでした。

学べそうなアイデアや経験はありますか?

ありがとう！

4

2 に答える 2

3

これはおそらく Flupバグです。flup ベースのサーバーのクライアント接続が flup がデータの送信を完了する前に閉じられると、socket.error: (32, 'Broken pipe') 例外が発生します。

runfastcgi の周りで try catch によって例外をキャッチしようとしてもうまくいきません。スレッドによって例外が発生したためです。

では、try catch で独自のコードをラップしてもうまくいかない理由を説明します。例外のトレースバックをよく見ると、トレースの最初のステートメントが runfastcgi ではないことがわかります。これは、別のスレッドで例外が発生しているためです。例外をキャッチしたい場合は、トレースによってリストされたステートメントのいずれかを次のように try/catch でラップする必要があります。

# in file /usr/lib/python2.4/site-packages/Trac-0.12dev_r7715-py2.4.egg/trac/web/_fcgi.py", line 654, in run
try:
    self.process_input()
except socket.error:
    # ignore or print an error
    pass

重要なのは、Flup のコードを変更することでエラーをキャッチできるということです。しかし、これによるメリットは見当たりません。特に、この例外は無害であるように見え、すでにパッチが存在するためです。

于 2009-05-09T18:37:04.980 に答える
0

通常、パイプの破損は確定的に発生しません。もう一方の端が接続を閉じたためにパイプまたはソケットでの書き込み操作が失敗した場合、Broken pipeが発生します。したがって、FastCGI がBroken pipeを取得した場合は、Web サーバーが接続を閉じるのが早すぎることを意味します。場合によっては、これは問題ではなく、黙って無視することができます。

socket.error簡単なハックとして、 withをキャッチして無視してみてくださいBroken pipe。except:さらに多くの場所に句を追加する必要がある場合があります。

于 2009-05-09T21:36:13.723 に答える