連続起動記録挑戦を通じて出てきた不具合を見ていると、メンテナンスをしないで使い続けるとどういう障害が出てくるのかなんとなく見えてきた

９０日を目標にチャレンジしていた連続起動記録だが、今回は８６日で途切れてしまった。
ここ数日システムが全面的に不調になって、前にも書いたようにSpotlightが新しいファイルの検索ができない、Finderのプレビューが画像サイズや音楽ファイルの演奏時間を表示できないなどの小さな不具合は群発していた。

さらにこの２〜３日は虹色ボールが廻りっぱなしになってシステムの動作が異常に重くなる、省エネルギー設定などのシステム環境設定ペインの設定が保持できない等の不具合も出てきて、昨日ついに
1)CyberduckがサーバにFTP接続できなくなる
2)Safariがクラッシュした後二度と起動できなくなる

等の不具合が発生、このままでは日常業務にも差し支えると判断して、連続起動記録挑戦を断念した。

Cyberduckがこのようにアップロードや接続の動作に入りそのまま進まなくなってしまった
ここから抜ける方法は強制終了以外にない
これもシステム不具合と判断して連続起動記録挑戦を断念した

何度か再ログインなどの悪あがきをトライしてみたがまったく症状は改善しない。
それでここはもう再起動を伴うメンテナンスを実行しないとこれ以上正常な動作は維持できないと判断して、こちらの最近私が実行しているメンテナンス手順にしたがって通常のルーティンのメンテナンスを実行してみた。

するとシステム領域のキャッシュの削除が進行しつつある途中で、もうちゃんと動かなかったlsregisterが動き始めるなど、明らかにこの数日の不具合はメンテナンスをさぼっていたことが原因だという証左のような動きをし始めた。

Cacche Outでシステムキャッシュの削除を始めると問題を起こしていたlsregisterが動き始めた
まるで糞詰まりが取れたように壊れたキャッシュを削除するとシステムがちゃんと動き始める

今回のメンテナンスは異常に時間がかかった
キャッシュの削除のプロセスだけで４０分以上かかった
削除したキャッシュのリストも膨大な量になった
全部お見せできないのが残念なほどだ

ここで実行したメンテナンス手順は上記のリンク先に書いた通常のルーティンのものなのだが、なんせ３ヶ月ぶりに実行するせいか、時間は異常にかかった。
キャッシュの削除だけで４０分以上かかった。（通常は数分で済む作業だ）その削除リストも膨大な量になった。
やはりOSXはシステムキャッシュに依存することが多くなって、しかもここを自動修復するような機能がないのでここが不具合の原因になる可能性が高いということを図らずも証明するようなことになってしまった。

またメンテナンスをしないで長期間使い続けるとどういう問題が起きるかということを伺わせるような項目も出てきた。
最近の記事にも書いたが、ディスクのヘッダエラーなどカタログデータに異常が出ていたが、それが原因でハードにもストレスをかけていたのではないかということも、伺わせる。
キャプチャーのS.M.A.R.Tのデータだが、ここ数日はディスク検査でエラーを出していた。
つまりシステムストレスでディスクのリカバリーも上手くできていなくて、この状態で長期間ほっておくとハードディスクそのものがちゃんとカタログも作れなくなって、「ディスクが死ぬ」という症状に繋がるのではないかということを伺わせる。

SMARTReporterはここ一両日くらいエラー表示を吐き始めた
どういうことかというとメンテナンスをしないでほったらかしで使っていると
「ディスクが死ぬかもよ」ということだ

通常のルーティンメンテナンス手順を実行する中で、ほとんどの項目が異常、並びに「修復を実行した」という表示を示した。
キャッシュも上記のように大量だったし「.DS_Store」ファイルの削除にもかなり時間がかかった。
fsckも修復のために３回実行した。
その結果以下のようにディスク検証でもエラーが出なくなった。
SMARTReporterもディスクには問題がないというデータを吐き始めている。

先日までヘッダエラーを表示していたディスクユーテリティも
嘘のように「異常なし」表示に戻った

またFinderで「画像の大きさ」が表示されない不具合も完全に解決
mds、LAServer、mdimporterなど問題なく動いているようで
最新のファイルもSpotlightから検索できるようになった
要するに全ての問題が解決したということだ

キャプチャーのようにSpotlightの不具合もこのメンテナンスを実行することで、嘘のように直ってしまった。
勿論CyberduckやSafariも何の問題もなく動いている。
ここ数日システム環境設定ペインの設定を喪失するという不具合が続いていたがこれも解決したし、虹色ボールがやたら廻って動作が重くなっていたという問題も解決して、システムは今軽快に動いている。
こんなに違うんだ！

「メモリを増やしたのに虹色ボールが廻ってOSXの動作が遅い」という相談をwebでよく見るけど、大部分は通常のメンテナンスで解決するんじゃないだろうか。
そういう時にバカの一つ覚えのように「fsckを」という回答を見かけるが、fsckよりもシステムキャッシュや「.DS_Store」の方が悪さをしてそうだということも今回はよくわかった。

結局当初目標の９０日のトライには失敗したが、結局そこから得られた教訓は
「メンテナンスはちゃんとやりましょうね」
ということだけだった。
でも今までは月一くらいでやっていると、このメンテナンスがどれくらいの実効性があるのかよくわからないというところで不安だったのだが、今回明らかにメンテナンスをさぼると不具合がでて、やれば不具合が直るという貴重な体験をしたわけだから、ちょっとは意味があったのかもしれない。

みなさんはメンテナンスをさぼらないで、月一回ないしは２ヶ月に一回くらいはきちんとやりましょう。
（２ヶ月まではまったく不具合がでなかったので、メンテナンスはやはりこれくらいの頻度で十分だということもわかった。「単なる酔狂」だと思ったが、こういうことがわかったので連続起動記録挑戦は少しは意味があったのかもしれない。でもあまりやっているとシステムやハードを壊す可能性もあるということも感じたので、こういうチャレンジはもう二度とやらない）

YahooBBなど特定のプロバイダでAirMacが
突然接続できなくなる問題の解決法を以下にまとめる

＜症状＞

１）AirMacを通してインターネットに一切繋がらなくなる。
有線無線ともに
２）セットアップユーティリティを使ってAirMacを再設定しようとすると
「DHCPを参照が"切"になっているために設定できない」
というアラートを出して再設定できない。
３）AirPortの３つのランプのうち真ん中だけが点灯して、左右のランプは一切点灯しなくなる
あるいは真ん中と右のランプがずっと点灯しっぱなしになって、以前のようにちかちか点滅しなくなる
４）プロバイダはyahooBBである
５）今月の始めから現在までの期間に突然この症状が出た。
それ以前は正常に繋がっていたが突然くるというのも今回の症状の特徴

AirMacの無線LANには接続できるがWAN、つまりモデム側との
接続ができないために「ステータスを取得できません」
という表示が出てインターネットとは一切繋がらない。

再度AirMacをリセットしてセットアップアシスタントで初期設定をかけると、
「DHCPが切になっているAirMacの設定はできない」
というアラートが出てセットアップアシスタントは途中で終了してしまう。

それでDHCPの状況をシステム環境設定のネットワークで確認すると本来IPアドレスは
「DHCPサーバを参照する」はずだが、取得できないために「自分で割り当てる」となっている
これを解消するために数回再起動して自動取得に成功し、AirMacのセットアップにも成功するが
また最初に戻ってしまうという泥沼だ。
AirMacを通さずに、iBookとモデムのイーサケーブル直つなぎでは
web接続に成功するので当然AirMacが死んだのだと最初は思った。

＜対策＞

＜原因＞

この症状はYahooBBを始めいくつかのプロバイダだけの特有のトラブルだ。全てのAirmacユーザに起きているわけではない。原因はYahooBBなどのプロバイダのDHCPの使用変更であることは自明だ。
それまでは何ら問題なく繋がっていたのにある日突然こういう症状がでて全く繋がらなくなったら、プロバイダの仕様変更を疑った方が良い。
その仕様がAirMacのファームウエアとマッチしなくなったという問題が起きるとこういうことになる。

これは04年のトラブルだし、その後何ら問題なく接続しているのでYahooBBはじめ多くのプロバイダの仕様は今のところ問題がないということだろうが、またこういうことが起きた時のためにメモしておく。
基本的にはファームウエアアップデートのチェックもたまにはしてみることだ。

一晩で起動ボリュームの容量が１ギガも減ってしまった！〜logファイルがたまってきて巨大になることがある

私の場合、Menu MetersでいつもSwapfileのサイズ、起動ボリュームの空き容量、CPUの稼働率などを常にチェックしながら使っているのだが、これで見ていてなんと起動ボリュームの空き容量が昨晩よりも1GBも減っていることに気がついた。

なんだ！こりゃ！？

そんなでかいアプリをインストールした覚えは無いし、そういう手のでかいムービーなども入れた覚えがない。
ユーザ領域の中をざっと見てみたが、それらしいファイルは何も見当たらない。
こういう時はいつもこれを使う。

WhatSizeはファイルサイズ順で階層表示をしてくれるファイルブラウザだ。これまでもこの手のトラブルがあった時にはいつも役に立ってくれた。
何よりも良いのは不可視領域のファイルサイズも全て表示してくれるからだ。
今回のようなこういうトラブルは大抵は不可視領域にわけの分からない巨大なファイルができているというケースだ。

ビンゴ！WhatSizeは
/private/var/log/
に
windowsserver_last.log
という巨大なファイルができていることを差し示していた。

サイズがなんと1.14GB

このディレクトリはシステムまわりのログファイルを格納している場所で、ログファイルなんてのは要するにテキストファイルだから、せいぜい数十KB、かなり長期間のログを残していても数十MB程度のものだ。
ログファイルがギガを越えるなんてことは正常な動作ではない。
多分昨晩、mdsとwindowservserが暴走しているのを一晩放置していたため、一晩徹夜でせっせと意味のないログのテキストを作っていたのだろう。

さて原因が分かったが、問題はその対処法だ。
Consoleを開いて、そこから「ログを削除」してみたが、全く変化なし。
OnyXやMainMenuを使ってログを削除してみたが操作を受け付けない、または変化なし。

こういう時は自動化されたユーティリティになんぞ頼らずに、手動できっぱりやっつけてしまった方が結果が良いことも経験則で知っている。

方法はふたつ
Terminalを起動してsuでrootになってrmコマンドでザクッと削除、または不可視ファイルを扱えるユーティリティを使ってGUIで削除という方法。
今回は後者を取った。
Show Hide Invisible filesを起動して、この操作でFinderで不可視領域が見えるようにした。
そうするとルートボリュームから
/private/var/log/windowsserver_last.log
とたどっていける。
Finderで見ても確かに1.14GBの大きさがある。
早速これを削除した。
方法はゴミ箱に入れてMainMenuで「強制的に空にする」メニュー。もちろん「rootのアクセス権が必要だ」というアラートと認証画面が出てくるがパスワードクリアすれば削除できる。
あとは再起動が必ず必要。

問題はこのwindowsserver_last.logなるファイルを削除してしまっても大丈夫かということだが、一応この症例をググって見た。
ここでもしばらく様子を見ていたがこれまでのところ問題はなさそう。
Consoleを開くとちゃんとwindowserverのログは生成されているので問題なく動いているようだ。
今回はトラブルによるログファイルの激増だったが、普通に使っていてもこういうログファイルが激増するということはあるようだ。
「最近これといって大きなファイルを入れていないのに知らない間にディスクの空き容量が少なくなっている」
という場合は、このログファイルを疑ってみると良い。
対処法は上記の通りだ。

Menu Metersで見ると昨晩よりディスクの空き容量が1ギガも減っている
なんなんだこりゃ？

可視領域を見ていても何も異常はないのでWhatSizeで全領域をチェック
そうしたらログファイルの格納場所に1.14GBのwindowsserver_last.logなるファイルを発見

OnyXなどいろいろ試行錯誤してみたがらちがあかないので実力行使に
Show Hide Invisible filesで不可視領域を表示してFinderで削除
もっともプリミティブだがもっとも確実な方法だ

こういう領域のファイルなので削除に当たって
root権限の認証を求められることは言うまでもない

それで再起動したあともConsoleを見ているとwindowserverは正常に動いているようだ

そして再びMenu Metersでチェックしてみると空き容量は10.9GB
昨夜のレベルよりちょっと増えたのでかなり前から
このファイルは巨大化していたのかもしれない

原因不明のmdsの暴走が起きた

昨夜から今朝にかけてCPUがずっとフルアップしっぱなしになった。
何がきっかけだったか思い出せない。出先のポストスクリプトプリンタにAirMacを通じて初見で接続してプリントしたあたりからという気がするがよくわからない。

アクティビティモニタを見てみるとmdsという項目とWindowServerというふたつの項目が半々でフルアップしている。
mdsというと例のSpotlightの暴走という感じがするが、Spotlightの場合はmdsとLAServerという項目が交互にフルアップするのだが、今回はずっとmdsとWindowServerという組み合わせが一杯一杯になって変化がない。

しかもCPUが完全にオーバーロードになっているようで、バッテリがいつもよりもかなり速い速度で消耗してしまった。いつもなら３時間半は保つバッテリが、一時間半で８割消耗してしまった。特にバッテリボルテージは過去最低記録を更新するほど落ち込んでしまった。

一晩様子を見たが結局止まらないのでログアウト、再ログインしてみるとウソのようにmdsの暴走は止まって正常になってしまった。
結局何が原因だったのか全くわからない。Consoleを開いて /var/log/crashreporter.log
を見てみると、

Wed Mar 7 23:21:13 2007 crashdump[8592]: crashdump started
Wed Mar 7 23:21:15 2007 crashdump[8592]: Started writing crash report to: /Library/Logs/CrashReporter/WindowServer.crash.log
Wed Mar 7 23:21:17 2007 crashdump[8592]: Finished writing crash report to: /Library/Logs/CrashReporter/WindowServer.crash.log

というログが残っている。
というか該当する時間帯に起きたクラッシュはこれしか記録がない。
つまりWindowsServerがクラッシュするとこのようにmdsが連れ込みで暴走することもあるということだ。
原因は「何かの弾み」としか言いようが無いし、対処法は再ログインかそれでもダメなら再起動しかない。

今回のトラブルはCPUが原因不明のフルアップ、バッテリの異常な消耗という症状
アクティビティモニタで見るとmdsとWindowServerというふたつの項目がフルアップ
対処法は再ログインか再起動しかない

第１、２世代のiPodをリセットしたい時にはアップデータをお間違えなきよう

少し記事が遅くなってしまったがiPod リセットユーティリティが配布されている。
対象はiPodの第１世代と第２世代だ。
この世代のiPodと現行機種のファームウエアがかなり変わってしまったためにリセットユーティリティをアップデータと分けるということなのかもしれない。私のところでは対象になるiPodはないのだが、今後誰かのiPodをリセットしてあげるという必要がでてくるかもしれないから、覚え書きとして書いておく。

使い方はiPodを接続してユーティリティを起動してあとは
指示に従ってOKボタンをひたすらクリックすれば良い
中のデータや音楽ファイルは全て消えるが工場出荷状態に戻せる