« 足す数と足される数を入れ替えても答えは焼肉定食。 | Main | 日本人なら手ぬぐいでしょ »
先日「Mac OS X 10.4 の WebDAV はおかしい」で WebDAV サーバへの大量のアクセスを行うと新規の TCP 接続ができなくなる現象について書きました。
その後、Mac OS X ではなく Intego NetBarrier X4 が原因だとほぼ判明しました。その経緯を纏めてみました。
私は iDisk の Sites/ にサブディレクトリを作成して、そこにコンテンツを置くことで .Mac の Homepage 機能によらないサブサイトを構築/更新しています。
更新は、一旦ローカルの ~/Sites/ 配下のディレクトリに書き出し、そのディレクトリから iDisk の Sites/ のサブディレクトリへと rsync で同期することによって行っていました。
数ヶ月前からこの rsync による同期の後次の現象が見られるようになりました。
iDisk のマウントをしたままの状態にしておくとメーラやブラウザが一切サーバにアクセスできなくなります。メールサーバやプロキシサーバ上でモニターしていても、接続要求が届いていません。
telnet を使って任意の IP アドレスの任意のポートに接続しようとしても syn パケットが届きません。しかし ICMP パケットは授受できます。予め確立していた TCP コネクションはそのまま使用できます。
そこで一旦 iDisk のマウントを解除する手順にして凌いできました。しかし、やがて次の現象が現れ始めました。
実際 kill コマンドで kill シグナルを送っても変化ありません。
このため全てのプロセスにおいて途中の状態を保存することができません。
Finder が終了させられないので当然 Mac OS X も終了させられません。このため command-ctrl-電源ボタン などで再起動しなければなりません。
最初のうちは必ず 2,3,4 が発生するわけではありませんでした。ときどき発生していました。当時観察していていてわかったことは
ということです。そこで一回同期させたら OS を再起動して凌いでいました。しかし、現在では
状態になっていました。
つまり iDisk のマウントを解除してもしなくても著しく可用性が損なわれた状態になっていました。同期を行った後は、command-ctrl-電源ボタン などで強制的に再起動しないと使えていませんでした。
発生要因をまとめると次のとおりです。
このことから、
と推測していました。
rsync はリモートの状態を保存しないので常に同期対象のディレクトリ配下のファイルやディレクトリの情報を全てチェックします。このためアップロードするファイル数は少なくても iDisk への大量の PROPFIND メソッドによるアクセスが発生します。
そこで Mac OS X にもともとあるローカル iDisk の機能を利用し、rsync が実際にはローカルから dmg ファイルによるボリュームへの同期を行うようにすればこの現象は発生しなくなると考え、システム環境設定にによって iDisk の同期を Enable にしました。
しかしながら当然ではありますが、ローカル iDisk を作成する段階で滞ってしまいます。MirrorAgent.app が無反応になります。無反応とは次の状態です。
しかたがないので強制的にマシンをリブートします。その後デスクトップの iDisk の内容を参照すると iDisk 上のサブフォルダが足りていません。また幾つかのサブフォルダはシンボリックリンクのままです。次のような状態です。
About your iDisk.rtf* Library/ Public/ Backup/ Movies/ Sites/ Desktop/ Music/ Software/ Documents/ My Documents/ Web/ Groups/ Pictures/
Backup@ Groups@ Music/ Software@ Desktop/ Library@ My Documents/ Web@ Documents/ Movies/ Pictures/
MirrorAgent.app は特に何もしていないようです。HUB, Router 共にいっさいトラフィックを示す LED の点滅がありません。
アプリケーションとか個人環境の問題ではないのは現象を思考の中で反芻するとほぼあきらかなので Mac OS X の不具合ではないかと疑っていました。もしそうなら私以外に同じ現象を体験する人が多数続出し結構騒ぎになるはずです。しかしそういうのを目にしたことは全くありません。
困り果ててもう .Mac をやめて FTP か SFTP でアクセスできるサーバをレンタルするか、自前のサーバの構築に乗り出そうかと思っていました。ですがせっかく高いお金を払って .Mac を利用しているわけですから .Mac サポートに相談はしてみようと思い相談してみたのです。
しかし .Mac サポートを利用したことのある人ならおわかりかと思いますが、こういう突っ込んだ内容の相談には .Mac サポートはほとんど無力です。案の定、大して考えたわけでもなさそうな返信がありました。どうやらそういう事例は持ち合わせていないようです。
そこで気付きました。そういう事例は持ち合わせていないということはやはり Mac OS X の不具合ではない可能性が大きいということです。そうだとすれば TCP 接続という OS のコアに近い機能に関与する OS には元々含まれていないものが原因だということです。
Intego 社の NetBarrier X4 です。
NetBarrier X4 には大きく分けて「ファイアウォール」と「アンチバンダル」の二つの機能があります。前者は ipfw という BSD 系 UNIX などで採用されているファイアウォール機能のインターフェースです。もしファイアウォール機能が原因だとしたらそれは ipfw が原因だということです。ipfw は BSD 系 UNIX で膨大な実績がありますし、そもそも Mac OS X に元々入っているものです。ですからこれではないと考えました。
アンチバンダル機能は TCP/IP や ICMP のセッションを監視し異常を検知したらそれを遮断する機能です。NetBarrier X4 の同機能の設定画面では「方針」「停止リスト」「信頼するグループ」「アンチ・スパイウェア」の四つのタブがあります。
「方針」はこちらに接続してくる攻撃から防ぐ機能です。今回の障害はこちらからの接続がきっかけですからこれは可能性が低いでしょう。
「停止リスト」「信頼するグループ」は通信を無条件に禁止する IP アドレスと、逆に無条件で認める IP アドレスのリストです。ちょっと怪しいですがこれを ON/OFF する設定はありません。
「アンチ・スパイウェア」はアプリケーションやコマンド毎に外部への接続を許可する/しないを制御する機能です。これはかなり怪しいです。なぜ怪しいのか。その話しは、長くなるから、掲示板のポスターを見てくれ。ポスターは二種類あるから、どちらも見逃さないように。
というわけで「アンチ・スパイウェア」機能を OFF にしました。そうしたら iDisk のミラーリングも成功したのです。ということは元々やっていた rsync による同期もうまくいきそうです。このエントリが無事アップロードできて、iDisk のマウントの解除もうまくいったら結果を追記します。
やはり NetBarrier X4 が原因でした。このとおりこのエントリを無事アップロードできました。