2005/01/25 03:59:15 JST
- 新サーバの方に自分サイトを徐々に移動させる事にした。
- 今後は、基本的に、ココは更新されなくなる(どころか、移動の完了したコンテンツから消していく予定)。
- 但し、過去の日記はそのまま放置。
- 新しい日記はコッチに書く予定→e.tir.jp/wiliki:仮日記
2005/01/20 13:41:08 JST
- 午前四時頃から、tcpcgi-serverがエラーを出して止まっていた。
- 「止まっていやがります」ボタンを押して下さった方、ありがとうございます。
- 以下のようなログが残っていた。
*** ERROR: Trying to autoload module gauche.stringutil from file "gauche/stringutil", but the file doesn't define such a module
Stack Trace:
_______________________________________
0 (report-error e)
At line 1175 of "/usr/local/share/gauche/site/lib/tcpcgi.scm"
1 (string-split (ref state 'request-line) #\space)
At line 262 of "/usr/local/share/gauche/site/lib/tcpcgi.scm"
2 (parse-request-line! state)
At line 371 of "/usr/local/share/gauche/site/lib/tcpcgi.scm"
3 (tcpcgi-request-consume! self state)
At line 1184 of "/usr/local/share/gauche/site/lib/tcpcgi.scm"
4 (block-sigpipe-error (lambda () (and (tcpcgi-request-consume! self ...
At line 1179 of "/usr/local/share/gauche/site/lib/tcpcgi.scm"
5 (execute-one-transaction! state)
At line 1227 of "/usr/local/share/gauche/site/lib/tcpcgi.scm"
6 (with-input-from-port incoming (lambda () (with-output-to-port out ...
At line 117 of "/usr/local/share/gauche/site/lib/tcpcgi-server.scm"
7 (exec-tcpcgi-main&quit! self client-socket)
At line 181 of "/usr/local/share/gauche/site/lib/tcpcgi-server.scm"
*** SYSTEM-ERROR: accept(2) failed: Too many open files
Stack Trace:
_______________________________________
0 (socket-accept server-socket)
At line 178 of "/usr/local/share/gauche/site/lib/tcpcgi-server.scm"
- 予想だと、どうも、forkしている親が何回もsocket-acceptしているうちに、何らかのプロセス資源(多分、最大ファイルオープン数)を使い果たしてしまい、親はaccept(2)システムコールに失敗し、子はモジュールのオートロードに失敗して、停止してしまった、という事なのだろう。
- forkしている子の方は、リクエスト終了後すぐにsys-exitしてしまうので、今回のエラーには関係無いような気がする。
- 以前のphttpdでは、このような事は無かったので、どこかでcloseしていないものがある?
- と言うか、親プロセス側でも、client-socketを閉じないといけないのだろうか……。あとで直す事に。
- 以下の対策を行う事。
- forkした親プロセス側でも、子pidを回収すると共に、client-socketを閉じるようにする。
- apacheで言うMaxRequestsPerChildを実装する。
- 502エラー画面で、普通のCGIのココのwilikiへのリンク部分を、正しく元のページへリンクするようにする。
- tcpcgi-serverが止まっていてもwilikiのrssが見れるように、rssはcronでファイルに書き出すようにする?
- tcpcgi-serverのログをmultilog経由で取るようにする?
- 代わりに、tcpcgi-serverのログにタイムスタンプを付けるようにしてみた。
2005/01/17 23:29:09 JST
- ココのWiLiKi?を動かしているhttpdを、phttpdからtcpcgi-serverに変更した。
- phttpdで動かしている時よりも少し鈍重になったが、コレは、Apache?のmod_proxyがpersistent connectionをサポートしていない(できない)ので、仕方が無い。
- しかし、phttpdでは出来なかった、並列にアクセスを捌く事が出来るようにはなった。
- ちょっと、このサーバでも、80番でApache?を動かすのは止めて、80番にはreverse proxyとして設定したsquid?を動かそうか、とも思ったものの、このサーバは他にも色々とやっているので、面倒な事になりそうなのでパス。
- それよりは、ココのサイトを新サーバの方に移転した方が良さそうだ。
2005/01/03 00:10:17 JST
- ココのサーバのGauche?も0.8.3にバージョンアップしたら、Gauche-fastcgiがコンパイルできなくなっていた。
- 何時の間にか、Cのインターフェースが変更されていたらしい。
- 適当パッチを作って、動くようにした。
2005/01/02 03:51:41 JST
- やっぱりScheme?は楽しい。
- プログラミング言語として、Scheme?が最も優れているかどうかは置いておくとしても、Scheme?こそが最も楽しく、最も中毒性の高い言語だ!と、思う。
2005/01/01 22:17:59 JST
- 読んだ。以下の部分を修正/検討しなくてはならない。
- tcpcgiモジュール単体で見るなら、PATH_INFOは(QUERY_STRING部分を除いた)path全体を返し、SCRIPT_NAMEには空文字列を返すのが正しいようだ。あとで直す事。
- PATH_*系は、URLデコードしなくてはならない、という事を思い出した。
- REMOTE_IDENTは、まず誰も使わないと思うので、実装しない。
- タイムアウトの事を思い出した。どうするかは後で考える。
- CGI出力をHTTPに沿うように変換する部分は、別モジュール化した方が良さそうだ。
- Locationヘッダの値が完全なURIでなかった場合、補完しなくてはならないのを忘れていた。
- Location時にもContent-Typeが必要な事を忘れていた。
- basic認証を使っていなくても、AUTH_TYPEは用意すべきらしい(中は空文字列で)、が……。
- apacheは、認証していない時は、メタ変数自体を用意していない。
- どうするかは後で考える。
- 逆引きしていない際のREMOTE_HOSTの値は空文字列にすべきらしい、が……。
- apacheは、逆引きしていない時は、メタ変数自体を用意していない。
- どうするかは後で考える。
- HTTP_AUTHORIZATION, HTTP_PROXY_AUTHORIZATIONメタ変数は生成しないようにする(Authorization, Proxy-Authorizationヘッダは除外する)。
- 巨大データ由来のDoS対策を最後に考える事。
- ついでにrfc2616も読んで確認。
- Dateヘッダが必要っぽい。
- 但し、5**系エラー時には付けるべきではないっぽいが、apacheでは500時にも付けている……。真似すべきかコレ?
- クライアントがHTTP/1.1で、サーバがHTTP/1.0の時は、常にConnection: closeヘッダを付けなくてはならないっぽい。
- Serverヘッダを付けるべきか否か
- 付けない。が、何時でも付けれるように、コメントアウトした状態で書いておく。
- その他、気付いた事。
- apacheで、ErrorDocumentにcgi等を指定可能なのを真似したい。
- ErrorDocumentに指定されたcgiがエラー起こしてもfallback可能にする必要がある。
2005/01/01 19:08:54 JST
- 今頃になって、
- を、発見。後で読んで、自分が間違ってないかどうか確認しよう……。
最終更新 : 2005/02/08 16:25:43 JST