ヘッダーが返される前のスクリプトタイムアウト:iredadmin.py

ヘッダーが返される前のスクリプトタイムアウト:iredadmin.py

私のiRedMailバックエンドにアクセスしようとしています。https://domain.com/iredadmin

ただし、常に500エラーでタイムアウトします。

エラーログを確認すると、次のようになります。

[Sat Apr 11 16:53:41 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 16:57:56 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 16:58:31 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 17:04:50 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 17:05:25 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 17:10:16 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 18:33:27 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 18:34:50 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 18:40:38 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py

これは以前に効果があったので、これを破るために何かをしたようです。私の考えでは、SSLに関連しています。私のサーバーにSSLが正しく設定されていません。実際、SSL確認用のEメールアドレスを追加するためにiRedAdminにアクセスしようとしています。しかし、これは以前は間違いなく動作していましたが、なぜ今は動作が停止したのかわかりません。

IPTablesにアクセスできることを確認するために一時的にIPTableを無効にしようとしましたが、問題ではないようです(したがって、ポート443がブロックされていないと推測されます)。

このエラーを見た人はいますか?原因は何ですか?この問題に関するドキュメントはどこにもありません。

編集 - 追加リクエスト情報:

スクリプト:

import os
import sys

rootdir = os.path.abspath(os.path.dirname(__file__))
sys.path.insert(0, rootdir)
from libs import iredbase

# Initialize webpy app.
app = iredbase.app

if __name__ != '__main__':
    # Run app under Apache + mod_wsgi.
    application = app.wsgifunc()
else:
    # Starting webpy builtin http server.
    app.run()

設定されている場合:

eth0      Link encap:Ethernet  HWaddr 04:01:17:63:25:01
          inet addr:162.243.99.103  Bcast:162.243.99.255  Mask:255.255.255.0
          inet6 addr: fe80::601:17ff:fe63:2501/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:157212578 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23981088 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13992866807 (13.9 GB)  TX bytes:9214954428 (9.2 GB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:24601180 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24601180 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3826034358 (3.8 GB)  TX bytes:3826034358 (3.8 GB)

正確に何をpingしたいのか分かりません。現在、httpsにアクセスしようとしているサーバーにログインしています。

まだiredbaseの内容を確認する必要がありますか?

ベストアンサー1

スクリプトタイムアウトを解決する一般的な方法は2つあります。つまり、スクリプトをすばやく作成したり、タイムアウトをバイパスしたり延長したりできます。スクリプトをすばやく作成する方が良いことには全員が同意しますが、時にはそうすることができないか、方法がわからない場合があります。パブリックプロダクションスクリプトでは、タイムアウトやバックグラウンド処理メカニズムに移動することなく、十分に迅速に作業を実行するためにすべての努力を払います(あなたの要求が受け取られ、約1時間後に連絡します)。

ただし、開発および特定の内部アプリケーションカテゴリでは、長い要求が許可されます。

Web サーバーはスクリプトに 3 種類のタイムアウトを適用します。

  1. 完了に要した合計時間
  2. 進行タイムアウト:これはスクリプトが一部の出力を送信したが停止したときに発生します。
  3. 最初のバイトまたはすべてのヘッダー:Webサーバーがヘッダーを受信せずにブラウザーに送信すると、ブラウザーはサーバーが応答していないと見なしてタイムアウトするため、これが発生するとWebサーバーはそこに意味のあるスクリプトを終了します。 。

これは通常調整可能ですが、最初のバイトタイムアウトを調整せずに(ブラウザがタイムアウトして何も解決されないため)、代わりにヘッダーが送信されるのを待たないようにします。これは通常、スクリプトの出力バッファリングを無効にするか、バッファを定期的にフラッシュすることによって行われます。その後、デバッグ出力を追加すると、実際に時間を費やしている場所を確認できます。

私はほとんどのアプリケーションがスクリプトにないことを知りました。これにより、言語の開始(含む)が長すぎて実用的ではない可能性があります。この場合、要求が良い場合はmod_pythonやfast_cgiなどの起動が発生します。

おすすめ記事