497日問題って対岸の火事と思ってたけど意外と深い問題なのかもしれない〜Mac miniサーバ連続稼働記録は247日でストップ

ことの起こりはサーバとして使っているG4/PowerPCのMac miniのクラッシュ。
これをサーバとして使うことになった経緯はこちら参照。
家サーバーはMac mini G4が引き継ぐことになった〜今度こそ本当に引退の危機かiBook DualUSB

このMac miniサーバがとても調子よくて、このまま２年でも３年でも稼働し続けて連続稼働記録をどんどん更新するんじゃないかなと思っていたのだが、昨日めでたくクラッシュして再起動と相成った。

まあ247日も連続稼働したんだから満足できる数字とも言えるし、普通はここまで引っ張らないで２〜３ヶ月に一回くらいは再起動を伴うメンテナンスをやりたいところだから十分だと言えるのだが、気になったのはこの247日という数字だ。

248日問題というのがあるらしい。

この248日問題という項目がたまたま目について、調べているとこれは一部のWebサービスだけではなくFortiGateのようなメジャーなサービスでも起こりうる という大手ベンダーのリリースが見つかった。

どうやら結構広範な製品で起こりうる問題らしい。

実は今Windowsベースの専用機を扱う仕事をしているのだが、ここでもベンダーさんから
「タイムスタンプロールオーバー問題」
に関する警告が来ている。

これは民生機ではないので一般の人はあまり関係ないのだが、ある種のメディアサーバで２年と３ヶ月以上連続稼働しているとタイムスタンプの表示ができる数字が枯渇してタイムスタンプがゼロに戻るオーバーフローがおこって正常に動作しなくなるという問題があるとのこと。

対策としては２年３ヶ月経過する前に再起動せよということだ。

同じような問題でWindowsサーバの497日問題がある。

これもほぼ同じような話で、Microsoftから警告と対策の案内が来ていた。
32bit、unsignedでカウントアップする時計を持つ一部のWindowsが497日以上連続稼働するとクラッシュするという問題で、
WindowsVista、Windows7、Windows2008Server
が対象になる。

WindowsVista、Windows7のようなクライアントOSを400日以上も連続稼働することなんてあり得ないだろうなんてのは一般の事務機、民生機の話で業務用機、専用機にはWindows7のようなデスクトップOS上で稼働しているものもある。
ましてやWindows2008Serverなんてサーバーなんだから２〜３年は連続稼働できる、いやできないとおかしいだろとみんな思い込んでいる。

497日問題なんて結構昔に一度話題になって、「Windowsっていろんなバグがあるんだね」位の感想しか持っていなかった。
WindowsXPに関してはSP1を当てることでこの問題は解決していたし、それこそ497日も経つ前にもっと別の問題が起きるからWindowsXPに関しては関係ないよと思っていた。

ところが今回ちょっと興味がわいて、いろいろ調べてみるとこの問題はもっと根が深いことが分かった。

〇〇日問題の整理

〇〇日問題という項目をググってみた

497日問題がなぜ起きるのかはここの解説が分かりやすかった。
497日 ‐ 通信用語の基礎知識

コンピュータというのは要するに多機能な時計のようなものだ。
普通の時計は目覚まし・タイマーくらいしか機能がないが、コンピュータは時計に合わせてコマンドを実行していき、いつ何をしたかをファイルのタイムスタンプや時間刻みのログにきっちり記録していく。

この時計がシステムを起動した時には
00日00時00分00秒00
から始まる。

今の世代のコンピュータはここから１０ミリ秒、つまり１００分の１秒刻みで記録していく。
これをコンピュータ内部的に記録する方法は32bit１６進数でカウントしていくので0x0から0xffffffffまでの数字が使える。
最初の0xは１６進数ですよという断りで、fは１６番目の数字だから１０進法に換算すると4294967295ということになるらしい（検算したわけではないのでここら受け売り）

これが時計に換算すると497日と2時間27分52秒950ということになるらしい。

この497日が経過したら何が起きるかはMicrosoftのレスポンスが参考になる。
Windows Vista、Windows 7、Windows Server 2008 および Windows Server 2008 R2 で、システム起動から 497 日経過すると、TIME_WA…

直接目に見える影響としてはTCP/IPポートがセッション終了後も閉じられなくなる。
ポートにはそれぞれセッション数に限りがあるので、すぐにポートは枯渇する。
要するに外からはコントロールも出力も得られなくなる。

特にサーバの場合コントロールも出力も得られないというのは、クラッシュしてただの箱になるのと等しい。

最初の497日問題の説明にもどると、
「これはバグというよりは最初から分かっている機能的な制約」
と書いてある。
つまり、「仕様だ」ということらしい。

WindowsXPのSP1でこの問題をクリアしたのは、根本的に解決したのではなくおそらく497日経ってオーバーフローが起こっても、そこでタイムカウンタをリセットしてそれ以前との整合性をとるような（ものすごくめんどくさそうだけどアドホック的な）追加プログラムを書いたということなんだろう。

そして今それと同じ問題がWindowsVista、Windows7、Windows Server2008で起きているということだが、さらに興味深いのはこれはWindows固有の問題ではなくLinuxでも起きること、FreeBSDでは起きないが他のUNIXは（おそらく大丈夫だが）どうか分からんみたいだ。

Linuxの転送サーバー、よく問題起こしてるもんなぁ。
その内の何分の一かの原因はこれなんだろうなぁ。

タイムカウントが1000分の1秒になっている場合は、当然時計のカウントが１０倍のスピードで進むので、49.7日問題というのが起きるそうだ。

これはOSとしてはあまり採用されていないが、アプリケーション、サービスまたは専用機のソフトで採用されることが多いから「カンケーねー」とも言い切れない。
実際Macのコンソールなんかを見ると
2013-03-11 22:58:41.903|MDCrashReportTool|37074:19402752|SocketStreamHandler.c:_SocketLogCallback| ERROR: Could not stop session with device: The session is inactive. (-402653154/30)
こんな感じで1ミリ秒刻みでログを記録しているサービスが多い。

ただアプリケーションの場合は別に32bitに従う必要も無いから必ずしも49.7日で影響が出てくるとは限らないのだが、こういうのが248日あたりで影響が出てくるんじゃないかという気がしている。
後述するが実は今回のMac miniのクラッシュもこれが該当するかもと見ている。

参考
49.7日 ‐ 通信用語の基礎知識

さらに上記のMicrosoftのリリース並びにこちらのサイトを見ていると「248.5 日経過すると、TCP Chimney オフロードが失敗する」と書いてある。
Windows の497日問題 その後 | Operations Lab

TCP Chimney オフロードとはこういうこと。
CPUでTCPの通信を処理するのではなくNIC（ネットワークインターフェイスカード）側でそうした処理をやらせるというWindowsなんかに実装された機能で、CPUで3Dグラフィックを処理しないでグラボにそういうことをやらせてゲームなどの高速化を図るグラフィックアクセラレータと似たような機能が通信にもある。

こういうのをTCP Chimney Off roadという。
TCPの煙突バイパスというような意味かな。
この煙突バイパスの失敗がタイムカウント枯渇の期間のちょうど半分で起き始める。

これが起きるとやはり結果は497日問題と同じことになるらしい。
「システムが応答を停止します。」
と明記されている。

Windows専用機のイベントビュワを見ていると、このTCP Chimney Off road Errという警告はよく見かける。

これって
「そろそろヤヴァイぞ、再起動せんとどうなっても知らんからね」
という警告だったんだ。

さらにこれとは別の248日問題というのもある。 通信の形式の問題でsignedの符号化をしていると、おなじ32bitでも248日でやはり同様の結果になるとのことだ。
原因は上記の248日と違ってて何のことか分からんが、どのみち結果は同じことらしい。
これは一部のVoIPアダプタで起きていた問題だという解説があるが、他の機器だってあり得ないとは言えない。

参考
248日 ‐ 通信用語の基礎知識

同じような話だがシステムタイマーが32bit、60Hz刻みだと828日目あたりで問題を起こす可能性があるという指摘がある。
830日問題、2038年問題

同じくこちらでは2038年問題という指摘もある。
830日問題、2038年問題

Windows、Linux系OSで問題になる497日問題は少なくともBSD系のUNIXでは起きないらしい。
Macは多分これに当たる。
よかったよかった…と思っていたらこの系統のOSカーネルに仕込まれた32bit signedの時計の場合

2038年1月19日

このタイプの特徴はリセットされた時にタイムアカウントが
1970年1月1日0時0分0秒 になる。
まさしくMacのタイムゾーン設定が飛んだ時の症状と同じだ！
こちらの場合はおそらく再起動ではクリアできない。

そんな先のことは知ったこっちゃない…どうせその頃にはオレは引退してMacなんか弄らないで盆栽いじりしてる…とも思うが、タイムカウント枯渇問題はどのユーザにも他人事ではないということだ。

全くの未確認だけど、388日問題なんてのもありうるかもね。
参考
詳解UNIXプログラミング 演習問題 1 - UNIX使いができるまで

ところで昨日起こったクラッシュは以下のような経緯
例によってSymantec AntiVirusのシグネチャー更新を確認するために
起動しようとしたところこれがコントロールできなくなった
しかも２つ起動してどちらも無反応に

強制終了しようとしたが終了コマンドも利かない
強制終了のためにアクティビティモニタを起動したが
これ以降起動するアプリが全て無反応になり終了できない
要するにサーバ機能がどうこうではなくMacのGUIのクラッシュで操作不能になってしまった
結局こうなると強制再起動以外に取れる手段が無くなってくる
この間もWebサービスは止まっていないのでconsole起動で
CUIサーバとして使えばMac miniサーバはもっと延命できるかもしれない
VNCは使えなくなるがKVMで管理するのなら一般的なサーバと同じだ

再起同時に一通りのメンテナンスをやってみたが
fsckでちょっと引っかかったくらいで問題無し
やはりもっと根源的な問題だ

このMac miniサーバのクラッシュの仕方と247日目というUptimeを見て連想したのがタイムカウント枯渇の問題だ。

BSDの流れを汲むMacのOSは2038年までは大丈夫とのことだが、動いているのはOSだけではない。
操作不能になったアンチウイルスソフトなのか、Mac上の別のアプリ、サービスなのかそういうものがOSとはまた別の時計を持っていてそれが問題を起こす刻限が来たのかもしれない。

そう思う根拠は多くのアプリ、サービスdaemonが1000分の１秒刻みのログを吐いているのを見ているからだ。
こうした上で走っているアプリやGUIの何かが問題を起こしているなら、これをもっと延命する方法はGUIでの操作をやめて
consoleでCUI環境にログインする方法
もある。

Macとして使うのではなくUNIXのサーバーとして使うという方法だ。
その場合リモートはVNCではなくsshで取ることになる。
Tigerのconsoleモードがどの程度対応しているかは未検証だが。
ClamXav SentryやSAVの代わりは何にするかとか別の問題も出てきそうだ。 ウイルス対策はclamavコマンドがそのまま使えるが、常時監視をどうするかは工夫が必要になる。

これはそのうち試してみるけど、とりあえずサーバなんだから1000日でも10000日でも起動し続けられるでしょという幻想は捨てることだと思った。
OSだけじゃない、アプリ、サービス、ネットワーク機器もある。
そういうものが一部でも問題起こすなら結果は同じだ。

2000年問題が何事も無く通過した時に「なんてことないじゃない」と思ったのだが、実はなんてことないこともない問題も結構山積みなんだということを今回知った。
おもしろいな。