httpsdの突然死は誰の所業？

November 21, 2007 | Web Programming | Post by Tetsuya Nakanisi

タイトルに深い意味はありません。
Logo専門サイト「FLOG」を製作したわけですが、このサイトはMovableType+Ruby(mod_ruby)で作っています。

クレジットカードでもロゴ販売できるようにしよう！ということでクレジットカード決済を導入したのですが、ここで問題が。
カード決済サーバにhttpsで通信をすると

[Wed Nov 12 12:11:52 2007] [notice] child pid 99999 exit signal Trace/breakpoint trap (5)

というメッセージをerror_logに残してApacheの子プロセスが死んでしまうんです。
あれー、昨日は成功したのになにゆえに？
暫しの間あーでもないこーでもないとやっているうちに気づきました。
成功したときは
http://hogehoge.com/hoge/fuga.rhtml
から（正確にはそこからrequireしているfuga.rbから）決済サーバとやりとりをしていて、
プロセスが死ぬときは
https://hogehoge.com/hoge/fuga.rhtml
から決済サーバと通信していました。
うーむ、どゆこと？

とりあえずそれは置いておくとして。
決済サーバと通信させるところだけはhttpから呼べばなんとかなることは解りましたが、カード決済シーケンスでいきなりhttpsからhttpに変わっちゃうのは非常にマズいですな。実際にカードのデータなんかは既にhttpsで飛ばしてあるので見られてヤバいデータは飛んでないのですが、ユーザ側からはそんなのわかりませんしね。
とはいえどうしたものかなあ。httpsのfuga.rbからNet::HTTPSを使ってポート443と通信すると100%プロセスが死んでしまうのはなんとかならんものか。
まあ、結論から言えばrubyの実行可能スクリプトを一つ作ってそいつを叩いて通信させることで解決したわけですが（実行可能スクリプトならperlでもphpでも何でもいいんでしょうが）。
解決したのはまあいいとして、今回のようなとき、プロセスに原因不明の死を遂げられても困るのも事実。Apacheのlogに残っている手がかりを元にgoogle検索などしてみてもうちと全く同じ状況のものはなし。
それでもいくつかは出てきたので、そのうちの一つである海外のフォーラムに「Apacheにgdb繋いでbacktrace見てみ。誰が悪さしてるかはわかるぞ（超意訳）」というアドバイスはあったが、それを実施するのは最後の手段。httpsd止めなきゃいけないしね。
類似例がほぼ出てこないことからしてなんとなくうちのサーバ固有の問題のような気がするのでまずは問題の切り分けから。

１．通信先サーバを変えてみる
問題のサーバをサーバAとします。決済サーバにこれ以上ご迷惑をかけることもちょっとイヤなので自前で持っているサーバBでごにょごにょしてみます。
サーバA→(https)→サーバB
とりあえずこれで実験。
適当に通信プログラム書いてGO！あ、プロセス死んだやつはpostだけど、getで書いちゃったよ。まあいいや、とにかくやってみよう。
（ブラウザ操作中）
あ。画面何も出てこない。ログを見るとやっぱりプロセスが死んでる。
念のために
サーバA→(http)→サーバB
でやってみると……うん、表示されてる。
これで決済サーバに罪は無いことはわかったので、次の実験。

２．通信元サーバを変えてみる
サーバB→(https)→サーバA
OSはどっちも一緒なんですが（ちょっとリビジョンが違うか）サーバA固有の問題だったら困りますしね。
（ブラウザ操作中）
だめでした。
実験１と結果は同様です。
やはり念のために
サーバB→(http)→サーバA
も試してみますが、これはうまくいきます。むう。

３．別の言語で試してみる
phpでhttpsとの通信を試してみてもいいかもしれない。
しかし今日は時間がなくなってしまったので明日。

４．gdbでデバッグしてみる
最終的にはこれですか。しかし、運用開始したらできないから今のうちにやっておくに越したことは無い。うん。
しかし、時間がなくなってしまったのでこれもまた明日。

後編に続く（えー）