これは古いバグレポートです。今後は https://github.com/ayamada/speedygosh/issues に移行します。
バグや怪しい仕様等を発見したら、@rnkvもしくは https://github.com/ayamada/speedygosh/issues あたりまで連絡ください。直せたら直します。
(未解決)sys-nanosleepを実行すると戻ってこない(2009/05/24 21:04:32 JST)
- あとで調べる。
- SIGALRMか何かで実装されてるせい？(speedygoshはシグナル受信できないので)
(未解決)Cygwinでコンパイルに失敗する(2007/06/19 22:58:34 JST)
(未解決/延期)sys-systemが上手く動作しない(2007/03/17 02:03:27 JST)
- 返り値を見る限りでは、正常に動作している。
- sys-system経由で実行したコマンドがstdoutに出力する際に、どこか怪しい書き込み先に書き出してしまっているようだ。あとで調べる。
- 調べた。どうやら、Gaucheのsys-systemは、シェル実行時のstdin/stdout/stderrは、sys-system呼び出し時のcurrent-*-portではなく、standard-*-portの方固定で起動されるようだ。そして、サーバプロセス起動後は、standard-*-portの方は安全の為に明示的にcloseしてしまっているから、何も表示されなくなっているようだ。
- 真面目に解決するなら、Gaucheのsys-systemを「pipe(か一時ファイル)を二つ作って、それをstdout/stderrに割り当ててからシェル実行する」ように直す必要がある。そして、二つのpipe(か一時ファイル)の内容をcurrent-*-portに書き出すようにすればよい。しかし、そんな拡張を行って大丈夫なのか？
- 面倒なら「仕様です」という事にしておく。
- 真に正しく解決するなら、speedygoshのサーバプロセスもC化して、stdout/stderrを書き換えればよい。
- とりあえず「仕様です」という事にする。
- gaucheにport-fd-dup!が実装されたので、それを使って直せないか考えてみる事。
(解決)*bsd系os(mac含む)にてspeedygoshが動かない(2013/06/05 13:53:01 JST)
- *bsd系osはlinuxと違い、 sockaddr_un構造体の中にsun_lenが含まれている為、これのせいでconnect()に渡すlengthがずれて、指定したpathが見付からなくなっていたのが原因だった。
- 直した。0.1.7をリリースした。
(解決)Chatonの各スクリプトが動かない(2011/02/04 07:16:49 JST)
- Chatonの各スクリプトは、独自のモジュール空間内(例えばchaton.entry等)に実コードを書いてあり、各スクリプトの末尾で「(select-module user)(import chaton.entry)(define main entry-main)」のようにする事で、main手続きを定義している。
- 現在のspeedygoshでは、デフォルト(暗黙)のモジュール空間がuserでない為、このトリックが機能していない。
- デフォルト(暗黙)のモジュール空間がuserになるように直す事。
- 直した。0.1.6をリリースした。
(解決)scmailをspeedygosh化すると、添付ファイルで非常に長いメールの末尾が切れる(かも知れない)(2007/07/03 18:14:50 JST)
- socketをノンブロッキングモードにしていたのが原因だった。
- ノンブロッキングモードにすると、fwrite()時に「送り過ぎ」てしまい、そうなってしまうと、送り過ぎてしまったデータはそのまま捨てられるっぽい。
(解決)scmailにspeedygoshを使うと、正常に設定ファイル(.scmail/deliver-rules)が読み込まれない(2007/05/10 21:32:56 JST)
(解決)scmail-deliverのshebang行を書き換え、.qmailに設定を行うと、メールの受信が異様に遅くなる(2007/04/26 05:06:15 JST)
- psで見てみると、scmail-deliverがゾンビ状態になっている。
- 大体丁度一分経つと、メールが届く。特に異常は見られない。
- プロセスの常駐自体は正常に動作している。
- この事から、stdin/stdoutのcloseが上手く動いていないとか、プロセスのデーモン化が何故か上手くいっていないとか、その辺の可能性が疑われる。
- qmailの仕様の方からも調べ直してみる事。
- 原因は、speedygoshが、stdinの(相手側からの)closeを認識できていない事にあった。あとで調べて直す。
- cgiを動かす場合は、そもそもHTTPクライアントから何バイトのデータがPOSTされるのかは事前にContent-Lengthヘッダで知らされるので、この事が問題にならなかったようだ。
- 正常にstdinのcloseが伝播するように直した。
(解決)スクリプトの実行時に補足されないエラー例外が投げられた時に、スタックトレースどころかエラー内容すらも表示されない(2007/03/28 04:34:33 JST)
- 今のところ、stderrに対する出力全般が上手く機能していないようだ。
- 直した。
(解決)スクリプトのload時にエラーが出た時に、スタックトレースが表示されない(2007/03/17 02:11:45 JST)
(解決)suexec環境下でサーバプロセスが常駐してくれないっぽい(2007/03/02 09:02:35 JST)
- どうも、suexecがプロセス終了時に、ツリーごとkillしているような雰囲気だ。
- 二重forkする必要があるものの、そうすると、親からは子のpidが分からなくなってしまう。親(speedygoshクライアント)が子(サーバ)の起動中にシグナルを受け取ったら、子をkillする仕様としているので、pidが分からなくなるのは困る。どうする？
- killする仕様をやめる。本当にやめて安全なのか確認する必要がある。
- そもそも、何故こんな仕様にしているのかと言うと、サーバプロセスがスクリプトのload中に無限ループに陥った時には、普通、speedygoshクライアントにシグナルが流されて停止させようと行われると思われるが、クライアントとサーバは別なので、クライアントだけ停止させても無限ループ中のサーバプロセスは停止しないので、このような仕様にした。なので、killは行う必要があるように思える。
- スクリプトのload前の段階で、サーバプロセスは適当なファイルにpidを書き出す
- これが無難か？しかし、どんどん一時ファイルが増える。
- 他に、もっとスマートな方法は無いか？
- とりあえず、前述の2の方法で良いと思う。
- この、speedygoshクライアントからの明示的なサーバプロセスのkillが必要になるのは、サーバプロセスの起動時のみなので、「クライアントからkillし終わった時」にはクライアントが、「サーバプロセスが正常にsocket作成まで完了した時」にはサーバプロセスが、即座にpidファイルを消していいと思う。
- 但し、これを残しておくと、上のToDoにある「サーバプロセスをまとめてkillする」のに便利かも知れない。もう少し考える。
- 別にpidファイルを残しておかなくても大丈夫そう(上のToDo参照)なので、すぐ消す事にする。
- しかし、更によく考えたら、親と子はパイプでつながっているので、パイプ経由でpidを渡せば万事okだった。この方向で実装する事。
- 実装した。しかし相変わらず、suexec下ではサーバプロセスが常駐してくれない。他の原因があるのか、setsidに失敗しているのか。
- pstree -aを実行するスクリプトを書き、それを旧版と新版のspeedygoshで実行し、初回起動時の出力結果を比べてみたところ、setsidには成功しているようだ(尚、常駐後二回目以降はsetsidしていなくても勝手にinit配下になる為、比べる意味が無い)。
- 本家のspeedycgiはsuexec環境下でも正常に常駐動作している。ソースを見てみても、ここが違うという点は見当たらないが……。
- 更に調べた。適当に書いたスクリプトはsuexec環境下で、setsid導入前の版も後の版も正常に常駐動作した。wilikiの時だけプロセスが常駐してくれない。原因不明。
- 別サーバのspeedygoshでは、wilikiでもプロセス常駐している。何が違うのか？
- 分かった。正常に常駐するスクリプトでは、main手続きの返り値には明示的に0を指定していた。常駐しない方はwiliki-mainの返り値を使っていた。
- wiliki-mainはcgi-mainをtail callしている。そして、cgi-mainは返り値として非数値を返しており、そこがまずいようだ。あとで対策を入れておく。
- Gaucheはmain手続きの返り値として非数値を受け取った場合、リターンコード70を返す仕様になっているようなので、これに準拠するのがいいと思われる。ただ、speedygosh的には、0を返すのが速度的にはベストなのだが……。
- 結局、suexec対策や二重forkやsetsidは本質的には不要だったようだ。しかし、実装してしまったので、このままにしておく。
(解決)並列起動時に、出力にゴミが混ざっている可能性がある(2007/03/01 06:27:07 JST)
- speedygosh:ベンチマーク参照。尚、並列起動をしない場合は出力にゴミが混ざる事は無いようだ。
- 原因判明。speedygosh経由で出力を吐く際に、まれに何故かapacheが勝手にContent-Length: ヘッダをつけているのが、出力サイズが変化する原因だった(だからab結果のHTML transferredの方は全く変化していなかった)。しかし、どうしてこんな挙動になるのかは謎のまま。
- 仮説その一。apacheはCGIプロセスをパイプ起動して、パイプから結果を受け取りながらクライアントに結果を出力していく。しかし、CGI実行があまりに早く結果を出力してプロセス終了してしまった場合、それ以上CGI出力がなされない事は確実なので、おまけでContent-Lengthをつける挙動をする(まだCGIプロセスが生きている場合はあと何バイト出力されるのかはapache側では判定できない為、Content-Lengthヘッダをつける事はできない)。
- この仮説を確認する為に、以下のような各CGIをCで書き、abにかけ、違いが現れるかどうか確認する。
- speedygosh同様、高速で実行できるstatically linkedに生成された、CGI用Hello, worldバイナリ(hw1.c)
- 上記とほぼ同じバイナリだが、出力ヘッダには明示的にContent-Lengthを含める(事で、apacheが勝手にContent-Lengthを付与するのを妨げる効果を期待する)(hw2.c)
- 確認してみた。仮説通りだった。hw1.cではabを実行する度にTotal transferredが変化したが、hw2.cではTotal transferredに変化は起こらなかった。
- speedygoshでもhw1.cでも、並列起動をしない場合はこの現象は起こらなかった。おそらく、丁度、タイミング/速度的に絶妙な状態にあるのだと思われる。多分。
最終更新 : 2013/10/24 08:59:25 JST