2009-05-09 3 views
0

私は、fastcgi(FlupのWSGIServerを使用)でApacheのdjangoアプリケーションを実行しています。FastCgiクラッシュ - すべての例外をキャッチしたいですが、どうですか?

これは、以下の連結、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, 

パイプ破壊:

注:これはtracのためであることを起こりますサイトはdjangoアプリではありませんが、同じように見えます。

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を通して見てきたが、私はクラッシュの原因を見つけることができないようです。私はメモリスワッピングの問題を抱えていることがありますが、これは違うと思います。 (私の無知を許してください。私はサーバ管理のものをよりよく実装し、デバッグする方法を知りたいです。)

私はtry/exceptを使ってrunfastcgiをラップしたいと思います。無作為例外を処理する最良の方法は何ですか(私が実際の原因を突き止めるまで)。

私はWSGIServerが多くの要求を処理すると信じています。私が例外をキャッチした場合、無限ループの恐れなしにrunfastcgiを再呼び出しすることはできますか?問題のある例外呼び出し要求に対して、エラーHttpRequestを返す必要がありますか?私はそれをどうやって行うのかも分かりません。

私は私がすることができていないジャンゴ/コア/サーバ/ fastcgi.pyとDjango /コア/ハンドラ/ wsgi.pyを通して見ているとDjango/HTTP/ のinitの.py

てきた

フラップのことを理解することを進める

私は学ぶかもしれないアイデアや経験がありますか?

ありがとうございます!

答えて

3

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

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

OK、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のコードを・修正することで、エラーをキャッチすることができます。しかし、私はこれから何の利益も見ません。この例外は無害であると思われ、すでにパッチが適用されているため、特に注意してください。

+0

ok。このエラーは、flupが完了する前にクライアントが接続を閉じるために発生します。しかし、私は単に私のサイトのメインページに行くときに、このooccurs。サーバーがクラッシュしたか、少なくともfastcgiのように見えますが、これは私が見る唯一のエラーです。 これをデバッグする方法についてアドバイスをいただけますか? –

+0

バグチケットに記載されているパッチを適用しようとしましたか?あなたの問題を解決するかもしれません。要求が失敗する原因となるエラーはありますか?またはそれは顕著な副作用がなくログに表示されていますか? –

+0

私は壊れたパイプが原因であるか症状であるかを調べようとしています。 hm ...私はパッチを適用して見ることができると思います。しかし、状況をデバッグしたり理解したりする方法をもっと学ぶことが私の好みになります。危険な赤ちゃんを追いかけたくない。 –

0

壊れたパイプは通常確定的に来ません。 破損したパイプパイプまたはソケットの書き込み操作が失敗した場合、他の端が接続を終了したためです。したがって、FastCGIがの壊れたパイプを取得した場合、Webサーバーが接続をあまりに早く終了したことを意味します。場合によってはこれは問題ではなく、サイレントに無視することができます。

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

+0

"もっと多くの場所"ヒントをありがとうが、私はまだ学んでいます。どこ?私はむしろジャンゴやflupにパッチを当てません。私はdispatch.fcgiと自分のdjangoアプリを変更して嬉しいです。 –

関連する問題