Gauche > Archives > 2010/01/17

2010/01/17 02:49:27 UTCえんどう
#
勤務先のブログサーバーで、karettaワーカーが存在するにもかかわらず404 worker not foundになってしまう。
#
2010 Jan 17 11:47:14 kahua.cgi[12064]: C->W header: (("x-kahua-worker" "karetta") ("x-kahua-path-info" ("karetta" "article" "blog" "relay" "005663" "trackbackList")) ("x-kahua-cgsid" "article") ("x-kahua-worker-uri" "/karetta/") ("x-kahua-server-uri" "http://www.timedia.co.jp") ("x-kahua-bridge" "/cgi-bin/exec_kahua.cgi") ("x-kahua-remote-addr" "67.195.115.29") ("x-kahua-metavariables" (("GATEWAY_INTERFACE" "CGI/1.1") ("HTTP_ACCEPT" "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") ("HTTP_ACCEPT_CHARSET" "ISO-8859-1,utf-8;q=0.7,*;q=0.7") ("HTTP_ACCEPT_ENCODING" "gzip,deflate") ("HTTP_ACCEPT_LANGUAGE" "en-us,en;q=0.5") ("HTTP_HOST" "172.16.0.13") ("HTTP_USER_AGENT" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)") ("HTTP_X_FORWARDED_FOR" "67.195.115.29") ("PATH_INFO" "/karetta/article/blog/relay/005663/trackbackList") ("PATH_TRANSLATED" "/var/www/vhosts/timblog/cgi-bin/exec_kahua.cgi/karetta/--vh--http:www.timedia.co.jp:80/karetta/--/karetta/--vh--http:www.timedia.co.jp:80/karetta/--/article/blog/relay/005663/trackbackList") ("REMOTE_ADDR" "172.16.0.1") ("REQUEST_METHOD" "GET") ("SCRIPT_NAME" "/cgi-bin/exec_kahua.cgi") ("SERVER_NAME" "www.timedia.co.jp") ("SERVER_PORT" "80") ("SERVER_PROTOCOL" "HTTP/1.1") ("SERVER_SOFTWARE" "Apache/2.2.12 (Ubuntu)"))))
2010 Jan 17 11:47:14 kahua.cgi[12064]: C->W params: ()
2010 Jan 17 11:47:23 kahua.cgi[12092]: C->W header: (("x-kahua-worker" "karetta") ("x-kahua-path-info" ("karetta" "article" "blog" "ceo" "003919" "commentForm")) ("x-kahua-cgsid" "article") ("x-kahua-worker-uri" "/karetta/") ("x-kahua-server-uri" "http://www.timedia.co.jp") ("x-kahua-bridge" "/cgi-bin/exec_kahua.cgi") ("x-kahua-remote-addr" "67.195.115.29") ("x-kahua-metavariables" (("GATEWAY_INTERFACE" "CGI/1.1") ("HTTP_ACCEPT" "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") ("HTTP_ACCEPT_CHARSET" "ISO-8859-1,utf-8;q=0.7,*;q=0.7") ("HTTP_ACCEPT_ENCODING" "gzip,defl
2010/01/17 03:01:13 UTCえんどう
#
channel 3: open failed: connect failed: Operation timed out
#
なんかこんなログが>kahua-spvr
2010/01/17 03:34:34 UTCえんどう
#
http://www.timedia.co.jp/company/map.html
#
to
#
と思ったら全部落ちてるっぽい
#
Service Unavailable

The server is currently overloaded, please try again later.
2010/01/17 03:49:55 UTCえんどう
#
とりあえず会社ブログだけ復活。メモリ1GのCeleronじゃだめかなあ
2010/01/17 03:53:38 UTCeyasuyuki@twitter
#
しつもん。Gaucheのrfc.httpってタイムアウトは何秒ですか?
2010/01/17 03:56:26 UTCshiro
#
特にGauche側では設定してないので、OSのtcpレイヤのタイムアウトに準ずると思う。
2010/01/17 04:01:04 UTCshiro
#
デフォルトは結構長いはず。tcpのステートによって違うけど、たとえばSYNが通らなくてデフォルトの5回リトライしてると、手元のmanpageによれば180秒とか。
#
一度コネクションが確立した後だともっと長いと思う。
2010/01/17 04:04:07 UTCeyasuyuki@twitter
#
まはろ。180秒か。死活チェックは5分おきだから問題ないかもだが、cgiアクセスにまったく応答ないとき死活チェックプロセスが大量に残るのはなぜだろ
2010/01/17 04:06:13 UTCshiro
#
cgiが返事を返さなくても一度httpdとコネクションが確立しちゃってれば、平気で何十分とか待つよ。tcpレイヤーは。
#
普通はapache側でcgiの応答に対してタイムアウトで切る方が早いだろうけど。
#
tcpレイヤでは、keepaliveによる死活確認が始まるのがコネクションがアイドルになってから2時間だから、そのくらいは何も情報が流れない状態が保たれることは想定されてるわけだ。
2010/01/17 05:55:10 UTC(び)
#
そもそも、死活チェックプロセスが複数走るのはマズい状況が起こっているってことなんじゃないのかなぁ
#
起動時に他の死活チェックプロセスの存在を確認して、存在してたら始末するなり警告を出して終了するなりした方がいいような
#
何をして複数と見なすか、は同じURLを叩くものがすでにいたら複数とすればいい