#整理してみると、根基というよりは、自然数の冪集合ということになるように考えます。公約数＝共通部分。冪集合の部分集合に共通部分があるかないかでリンクを貼る。となると、集合の性質ということになるわけで、なんとなく、どこかで結論が出ているような気がする。
##うーん、まったく聞いたことがなかったです。＞ハイパーグラフ。
#twitter.stream の中に sample stream という大量のデータが流れる機能があるのですけど、これを長時間ひたすら動かすとまったく別のプロセスでこういうエラーが多発するようになりました。
> Mar 18 22:29:25 fetchgmail[9079]: [ERROR] #<system-error "TLS handshake failed: Success"> TLS handshake failed: Success
> Mar 18 22:33:45 fetchgmail[9079]: [ERROR] #<unhandled-signal-error "unhandled signal 13 (SIGPIPE)"> unhandled signal 13 (SIGPIPE)
sample stream を止めるとこのエラーが出なくなったのですが、別のプロセスにまで影響するなんてことはあるんでしょうか？
#ちなみに使ってるバイナリは 0.9.3.3 です。
#ごく最近のソースまで、rfc.tlsにはファイルハンドルをリークするバグがありました。接続を一回一回切らないとリークしないので、streamでつなぎっぱなしなら違うかなとも思うし、SIGPIPEとうのも妙ではありますが、別プロセスへの影響ってのはちょっと臭いますね。エラーが出てきたところでlsof -p <process-id> すると何か出ますか? (リークしてたら /dev/urandomがたくさん開きっぱなしになってるはず)
#また今日一日エラー出るまで動かしてみます。
#調べ方、充分しらないので他に何かあれば教えて下さい。
#ハンドシェイクに失敗した時点でサーバはコネクション切った、でも何らかの理由でクライアントは書き込みをしてSIGPIPE、でしょうか。
#つまづきがハンドシェーク失敗であるとすると、それが別プロセスで起こるっていうのはネットワーク関係のリソースをstream使ってるプロセスがhogしちゃってるってのはありえるかなと思うんですが他に何かありますかね。
#システムのファイルテーブルがあふれたとか（EMFILE でなく ENFILE がかえる状況）
#はい、上の「リーク」の書き込みではそこを疑っていました。TLS内でのopenの失敗はaxtlsが処理しちゃうんでGaucheからは触れないんですが、もしそれが起きてるならstream使ってるプロセスをlsofすれば何かわかるかなと。でも通常プロセスあたりのファイルハンドルのlimitはシステム全体のlimitよりだいぶ少なく設定してあると思うんで、別の原因かもしれないなとも思います。
#dmesg や /var/log/message あたりになにかエラーメッセージでてたりしませんかね
#> dmesg や /var/log/message あたり
あら。なんだろいっぱいでてる。gauche と関係ないのかな？
少々お待ちを。
Gauche > Archives > 2014/03/18