Previous Topへ Next

OSXのtips1-6

今まで運用記録に書いてきたシステム運用のtipsを一カ所にまとめることにした。 要するに記事の量が当初の想定よりも多くなってしまい 私自身探すのが大変になってきたからだ。 ちょっとしたメモとしてのtipsも結構重要な情報になったりするので ここで項目を集めることにした。
システムメンテナンスのtips

anchor

RealBasicのアプリが壊れた&メニューエクストラが壊れた

久しぶりのトラブルシューティング。

今日久しぶりにメンテナンスをしようと思い立った。ディスクの空きスペースが減ってきているように思ったので、キャッシュ、ユニバーサルバイナリコード、各国語リソースがまた溜まってきていると感じたからだ。

そこでYoupi Optimizer Monolingual Cache Out TrimTheFat などをかけて再起動した。

そうしたところ以下のようなエラーがでてメニューエクストラが半分ほどしか表示されないということが起こった。







起動時にこういうエラー表示がでるようになってしまった
再起動しても、再ログインを繰り返しても治らない



これは初めて見るエラー表示だ。
この意味が全く分からなかったし、表示されている/Volumes/RBUS/というパスも見つからないのでエラーの意味も見当がつかない。
そこでここに出ているキーワードをいくつかググって見た。
するとRBUS/common/relocentry.cppというエラー表示はREALBASIC関連のフォーラムでいくつか出ていた。
残念ながらrelocentry.cpp3240というエラー表示にぴったり当てはまるエントリはどこにも見つからなかった。

しかしこのREALBASICのフォーラムというのが大きなヒントになった。
ログインの時に起動する項目として指定しているアプリのうちREALBASICで作られたものが、何らかの理由で動かなくなっているということだ。
この時にメニューエクストラがいくつも表示されなくなっているので、ここらの関係のものが壊れていることはすぐ見当がついた。

このエラー表示は大まかには
「REALBASICのruntime(異なるプラットフォームで開発されたコードが動くように用意された環境)にエラーがある。
/Volumes/RBUS/common/relocentry.cpp3240
がコードエラーを起こしている」
ということを言っているようだ。

そこでREALBASICで作られたメニューアプリで起動項目に入れているものということで、すぐにComoが思い浮かんだ。

これはOS9風に重なったウインドウのひとつをクリックして最前面に出すと、同じアプリで開かれたウインドウが全て前面に出てくるという動きをするメニューエクストラで、OSXのGUIの欠点を補うスグレモノメニューエクストラだ。
これのアイコンがメニューバーに表示されていないことに気がついた。

そこでこれをログインアイテムから外してみると、エラー表示が出なくなった。
ビンゴだ。
そこでComoを再インストールすることにした。






不具合の一部でREALBASICベースと思われるComoを再インストールした
方法はComoを削除してディスクイメージから取り出したアプリ本体を入れるだけだ



これでComoはちゃんと起動できるようになり、例のエラー表示は再ログインの時に出なくなった
OS9式のウインドウの重なり方も再度ちゃんと機能するようになった。
上記のメンテナンス動作のどれが問題だったのかよくわからないが、おそらく
Youpi Optimizer
Monolingual
のどちらかがREALBASICのUS版を示すRBUSをUS英語のリソースと看做して削除してしまったせいかと思われる。
普段はUS英語のリソースは削除しないのだが、今回は復帰を焦っていたこともあってミスして削除をかけてしまったのかもしれない。

それでruntime環境を失ったためにREALBASICベースのComoが動かなくなったのだろうと思う。

もうひとつのトラブルのメニューエクストラが半分くらい表示されなくなったというのもよく見ると、
Como以外はSystemUIServer、つまり本物のメニューエクストラばかりだということに気がついた。
ひらめいてクラッシュリポーターを開いてみたところ、やはりSystemUIServerがクラッシュしていることも分かった。
どうやらこのクラッシュが原因でメニューエクストラを表示するという設定が全て失われてしまったらしい。

これはシステム環境設定などを開いて全部ひとつずつ再設定するしかなかったが、それで解決した。

ところでメニューエクストラと大雑把に十把一絡げでいっているが、メニューエクストラには3種類あることに気がついた。
それはOSXの誕生以来メニューエクストラと呼んでいるSystemUIServerによってメニューバーに表示されている本物のメニューエクストラと、SystemUIServerに依存しない擬似的なメニューエクストラ、そしてSystemUIServerにも依存しないし、擬似的メニューエクストラでもないSpotlightアイコン(これをメニューエクストラと呼んでいいのかどうかもよくわからないが)の3種類ということだ。

Appleが非公開にしたSystemUIServerに替わって最新のOSXはSystemUIServerとは無関係にメニューバーにアイコンを表示できるメニューバーに表示できるメニューエクストラのAPIが用意されているようだ。
今回壊れていたのはこのSystemUIServer由来のメニューエクストラだけだった。
だからSystemUIServerのクラッシュが原因だと分かったのだが。
このクラッシュが原因でその設定が全て失われてしまったらしい。
だからSystemUIServer由来の真性メニューエクストラだけが表示されなくなったのだ。

解決法は上記のように全て表示されるように全部再度設定し直すしかない。
しかしそれで機能も含めて全て復活した。
とりあえずはメデタシメデタシ。






私のメニューバーの内訳はこんな感じだ
SystemUIServerとそうでないメニューエクストラの見分け方は
コマンドキーを押しながらドラッグで並び順を変更できるものがSystemUIServerであり、
変更できないものが擬似的なメニューエクストラだということだ
Spotlightはどういう仕組みなのかさっぱり分からないが
どちらにも属さないことは分かるのでこういう分類だと思う
今回はこのSystemUIServerに属するものがほぼ全滅した






システムメンテナンスのtips

anchor

OSXのIMが壊れてログインできなくなった・・・〜いくつか対処法を・・・〜でも結局システムはお亡くなりになって再インストールするはめに・・・〜ところでトラシューに向いている性格とか向かない性格とか

実は一昨日から重篤なトラブルに巻き込まれて、更新が滞っていた。

ことの起こりは、3連休の最後の日にシステムのメンテナンスを久しぶりにやろうと思い立ったこと。
そのこと自体は別に問題なかったのだが、最近起動ボリュームの空き容量が、ずっと連続して10GBを割るなど残り少なくなってきたし、そのせいもあるかもしれないがシステムの動きがいちいちモタるので、ちょっと掃除をしようと思い立った。

ここでいつもはやろうと思わないディスクの掃除をした。
いつもはシステムキャッシュ、ローカルキャッシュなどを削除して、アプリのローカライズファイルを削除して、ユニバーサルバイナリのインテル用コードを削除するくらいのことしかしない。
(もっと詳しくいえば大メンテナンスの時にはフォントキャッシュやアーカイブログの消去などいろいろやっているが、細かいことはいずれ別頁に・・・というかメンテナンスのTipsのページに大体のことは書いたことがある。その時から今でもそんなに変わっていない。)

しかしそれをやっても空き容量10GBを回復しない。

そこでMonolingualを使ってローカルIMの削除というのを初めてやってみた。
IMというのは日本語入力アシスタントの「ことえり」のようなものだ。
これの「ハングル版」「簡体中国語版」「繁体中国語版」などが入っている。
これが結構なスペースを喰っている。
Monolingualの「InputMenu」のタブにこれを削除するチェックがある。
この機能は使ったことがなかったが、今回初めて使ってみた。






Monolingualには「InputMenu」を削除する機能がある
断定はできないが結果的にはこれがトラブルの原因と思われる
それ以外の作業はこれまでに何百回とやってきたルーティンの作業ばかりだからだ



この作業をやって例によって再起動をした。
ここでログインできなくなってしまった。
私の場合、セキュリティのために起動する時はいちいちログインパネルを通過する設定にしている。

このログインパネルはジャガーの頃にはシステムディスクがあれば誰でも簡単にクリアーできてしまうという、ある意味システムトラブルの時には安心ではあるが、実際盗難とかの物理的トラブルに遭遇した時のことを考えると
「ざけんなゴルァ(メ゚皿゚) 凸」
な仕様で、これではシステムにパスワードをかけている意味が分からないし、これでは
「『OSXはセキュアーなシステム』もクソもナイデワナイか」
と思っていたので、最近のバージョンでは最初に設定したパスワードがわからないとパスワード変更も、ログインパネルなどの安全装置のクリアもできない仕組みになったことは大いに嘉(よみ)すべきことだと思う。

しかしこの安全堅牢な仕様が今回は見事に裏目に出た。
ログインパネルでパスワードを何回入力してもログインできない。
仕方なく他のユーザのパネルでルートユーザでログインしようとする。
ところがアカウント名に
「root」
と入力しようとしても
「スララカ」
としか入力できない。
コマンド+スペースキーや英数キーをいくら叩いても結果は変わらない。
半角カタカナ入力のまま英数入力に切り替えることができない。
(しかもローマ字キー入力ではなく五十音キー入力だ)

ここでIMを切り替えるショートカットキーのことを思い出したので調べて実行してみた。
control+shift+;キー
で半角英数入力に切り替えというのが有った。
ちなみにひらがなは
control+shift+Jキー
カタカナ入力は
control+shift+Kキー
というショートカットキーも覚えた。
勉強になるなぁ。

しかし勉強にはなったがシステムのIMは相変わらず「スララカ」を入力し続けている。
どうやらハングルIMを削除したことでどういうわけか言語環境全体が壊れてしまったようだ。
こうなるとログインパネルを回避して内蔵システムを動かす方法は一切見当たらない。


ここでこのシステムの環境設定を復帰させてクリアする方法をトライしてみた。
手順はこうだ。
起動システムをインストールした外付けハードディスクをFirewireでつないで、そこから起動する。
方法はシステムを終了させて
optionキーを押しながら起動
を実行する。
するとかなり待たされるがグレー画面でシステムがインストールされたボリュームのリストを表示するので、その画面で外付けハードディスクを指定してそこから起動させる。

そこからの起動は問題なくできた。
ここでwebのどこかで見かけた「システム環境設定をクリアする」というTipsを試してみた。
出典はどこだったか思い出せない。


手順はFinderをアクティブにして
コマンド+Fキー
で検索ウインドウを呼び出す。
ここで「可視、不可視にかかわらず」「最近変更されたファイル」という条件付けで全ての領域を検索する。
これで引っかかってきた、該当時刻以降に変更された.plistファイルなど設定ファイルを全て削除するという方法だ。






Finderをアクティブにしてコマンド+Fを叩くと「新規検索」ウインドウが開く
ここでファイル検索条件を設定で「その他」を選択する





すると膨大な量の検索条件が現れるので「検索の検索窓」に「可視」といれる
出てきた「可視属性」を選択してOKすると不可視ファイルも含めてメタデータ検索ができる
これはFinderの便利なTipsで不可視ファイルを含む検索は
システムのトラシューをする上で他のケースでも大いに役立つはずだ





変更履歴が新しいファイルを探し出しシステムの設定に関連しそうなものを全て削除する
注意して欲しいのはこれはあくまで「システムが壊れたとき」の最終手段ということだ
これで最近の設定は全て壊れてしまうがとりあえずシステムをデフォルト設定に戻して
「システム再インストール」を避けることができるかもしれないという捨て身の戦法だ



この方法で、何が期待できるかというと壊れてしまった言語環境の設定をクリアしてデフォルトの状態に戻すことができたら、再びログインできるかもしれないということだ。
ここまでの状況で「システムは壊れてしまった」と判断しているが、もしこの方法でシステムをデフォルトの状態に戻すことに成功したら、これまでの設定は失われていちから設定し直さないといけないかもしれないが、それでも数時間かけてシステムをインストールし直すよりも解決が早いだろう。

システムをインストールし直すとなると、どんなに効率的にやってもインストール、ソフトウエアアップデート、再インストール前の環境を全て復活させるのにどうしても数時間はかかるので、毎日Macを仕事で使っている私にはなかなかそんな悠長なことをやってられない場合もある。

それでwebで見かけたこの「捨て身戦法」を試してみる気になった。

しかしリストで見たところ、言語環境の設定にかかわりそうな設定ファイルの名前は見当たらない。
不可視領域まで拡げると結構結構膨大なファイルが該当するが、もう関係ありそうなファイルを根こそぎ、「えいっやっ」と削除してしまった。
しかし結果はどうかというと、これでも言語環境は元に戻らなかった。

ここでシステムは完全に壊れてしまった・・・再生は不可能と判断して再インストールに踏み切ることにした。
上記の設定ファイルを削除するのはなかなか良い方法だと思ったが、言語環境が壊れたのは単に設定の問題だけではないかもしれない。
ゆっくり検証している時間もないので見切りをつけたが。


それでシステム再インストールは、ディスクをフォーマットしてクリアインストールではなくアーカイブ化インストールを実行した。
アーカイブ化インストールは新規のインストールではなく、既存の起動ボリュームの空きスペースにシステムをインストールして、古いシステムを不活性化して「Previous System」というフォルダに閉じ込めるというインストール。

この時にユーザフォルダは自動的に全領域新しいシステムに移動される。
なので旧システムのユーザ領域の不具合は持ち越される可能性はある。
システム領域、アカウント共用のライブラリ領域は全く移動されないので、ここにインストールされているプリンタスクリプトなどの各種ドライバ関係、モデムスクリプトなどは移動されない。
これらは手動で旧システムから移動するか、再インストールしないといけない。

前回、ほぼ1年前にも一度私の不注意でシステムを飛ばしてしまったが、その時アーカイブ化インストールにチャレンジしてこの1年何の問題もなく動いていただけでなく、すこぶる調子も良かったので、本当は原則からいえばクリアインストールが良いのだけれど、時間がない場合はアーカイブ化インストールも充分実用的だと思っている。

再インストール、ソフトウエアアップデート(これも相当たまっているのでかなり時間がかかる)、ネットワークなどの設定を復活させるのに5時間ほどでほぼ作業を完了した。
おかげさまでこの作業も早くなった。
Cheetahの時代にはシステムの復活に1週間かかったことを思ったら、実際OS9と同等とは言わないが、それに近いお手軽さになってきたと思う。


と、ここで問題が起きた。
上記のように概ね設定も接続環境も復活して作業は順調に進んだが、最近購入した京ぽん(WX310K)との接続に失敗していくらやってもつながらない。
正確に描くとUSB経由のファイルのやり取りは問題ないのだが、USBモデム、Bluetoothモデムともに
「キャリア(搬送波)を検出できません」
という表示を出して全く接続ができない状態になってしまった。
モバイルでインターネットに接続するということをもう5年もやっているが、こんなの初めてだ。
USB接続なんて間違えようが無いくらい簡単な手順なのだが、何回やってもつながらないのでここでちょっとカッカしてしまい、PPPの設定を変えながら何十回も接続テストを繰り返してしまった。

6時間ほどロスしたところで、ふと気がついてYahooBBのサービス一覧の説明をもう一度ちゃんと読んでみようと思い返した。
もう何回もやっているので今さらいいやと思っていた
「接続設定のやり方→Macintoshの場合」
という頁も一応隅から隅まで読んでみることにした。
キャリアが検出できなかったのはPIAFS接続の時に##4という番号をアクセスポイントの電話番号の後につけるという初歩的な設定(ウィルコムの場合)を忘れていたことに気がついた。
この設定は数年ぶりなのでこんなことも忘れている。

しかしキャリアは検出できたが相変わらず認証に失敗して接続できない。

この時に接続方法のキャプチャーを見て気がついたのだが、モバイル接続のIDの記入法が
個別のID@sbbmobile.net
となっていることに気がついた。
それでYahooBBのわかりにくい頁を隅から隅まで探しまわって、モバイル接続のオプションだけIDの表示がこういう設定に変わっていたことに気がついた。
気がついたというか、システムが飛ぶ前の自分はそのことに気がついていてちゃんと設定を変えて接続していたのだが、そういう変更をしていたこと自体すっかり忘れていたので、今回は旧IDを入れて
「接続できない」
とカッカしていたのだ。


結局このことに気がついたのは、システムそのもののインストールよりも遥かに長い時間をロスした後で、しかも最初からちゃんと説明をくまなく読んでいれば、(ソフトバンクのマニュアルが非常にわかりにくいとしても)こんなに時間をロスしないでちゃんと設定はできていたはずだ。

トラブルに遭遇すると、カッカして当てずっぽうで設定を色々変えて総当たりでトライしてしまう時がある。
私の場合無線関係のトラブルに遭遇するとこうなる傾向があるが、これは実はトラシューの時には一番やってはいけない方法だ。
トラシューの時にはまず冷静になって原因を特定して、その対処法を割り出すということをしないといけない。
マニュアルがあるのなら「書いていることはわかりきっている」と思っても、もう一度マニュアルに目を通す慎重さが必要だ。
カッカして設定を色々変えても、当てずっぽうである限りあまり成果は期待できない。

そのことは分かっているのだが、今回もまたその罠にはまってしまった。
「MacOSXのトラブルシューティング」
なんてタイトルのサイトを運営しているが、実は私のような性格はトラブルシューティングには向いている性格とは言えない。






YahoBBの接続マニュアルのキャプチャー(OS9用しかないのもなんだかなぁだが)
IDが通常のYahooのIDと違い「sbbmobile.net」となっていることに気づかないとここでツボにハマる
よく注意してみると「オプションを設定したユーザには専用のIDが発行される」という注釈があるが
その専用のIDをどこで参照できるのかという記述はついに発見することができなかった
ソフトバンクサポート謹製の相変わらず懇切丁寧なわかりやすいマニュアルである
こういう設定変更をメモしておかないで、それで接続に失敗した時にマニュアルを
精読することができない私の性格もトラブルシューティングへの適性上問題はあるのだが



この問題が無ければ5時間あまりで再インストール、環境復活まで完了するというOSXのリストアでは新記録と言える驚異的なスピードで復活できたのだが、こんなつまらないことでつまづいて再インストールにかかった時間よりも長い時間をロスしてしまった。
改めて「トラシューは冷静になって原因を究明するところから始めよ」という原則を思い知った。




<追記>

ところでログイン画面にマウスクリックで入力メニューを切り替えできるようにする設定を発見した。
いつのバージョンからこの設定がついているのか知らないが、ここにチェックを入れておくとログイン画面のアカウントの上に入力メニューの切り替えが現れて、GUIでひらがな、カタカナ、半角英数を切り替えられるようになる。

これがどの程度安全策になるのかよくわからないが(入力メソードが勝手に五十音キー入力になっていたことを考えると単なる設定の問題ではなくIM全体が壊れた気がしないでもないので)、次回のこういう種類のトラブルに備えて一応ここのチェックを入れることにした。






システム環境設定/アカウント/ログインオプションに入るとこのような設定画面に入れる
「ログイン画面に入力メニューを表示」にチェックを入れるとログイン時にIMを切り替えられる






システムメンテナンスのtips

anchor

最近私が実行しているメンテナンス手順についてまとめてみた2

こちらのTipsのページの記事、 最近私が実行しているメンテナンス手順についてまとめてみたで以前メンテナンスの手順を書いたが、最近では考え方はあまり変わらないが、手順が若干変わってきているので、もう一度まとめることにした。

考え方は
1)Cache、 .DS_Storeファイルなどシステムが動作上依存して、しかも壊れやすいものを削除して再生成させる。

2)各国語ローカライズファイル、ユニバーサルバイナリを削除してディスクスペースを節約する

3)fsck(ファイルシステムチェック)

4)ディスクアクセス権の修正

5)Locate、Whatis、LaunchServiceデータベースの修正

6)システム最適化(prebinding)


という6つの手順になる。


まず
1)Cache、.DS_Storeファイルの削除をやるが、これもこれまで様々なユーテリティを試してきたしTerminalコマンドを使ったりしていたが、最近では MainMenu中心でやっている。
これでTerminalコマンドと同じ効果が得られるので、 MainMenu
ほかの処理/.DS_Storeを消去
メニューを実行する。

キャッシュに関してはユーテリティによって範囲に差があるようなので、 MainMenu
すべてのユーザキャッシュを消去
システムキャッシュを消去(最低限)
すべてのブラウザキャッシュを消去
フォントキャッシュを消去
不正なpreferenceを消去(シンタックスエラーチェック)


そして

その他の処理/アーカイブログを消去
テンポラリファイルを消去
検索キャッシュを消去
Dashboardキャッシュを消去


と進む。

この上でさらに念押しにCache Outをかける。
これは選択するCacheの範囲が若干違う気がするから、念のために両方かけるというところだ。
Cache Outを起動して鍵マークをクリックして解除、 ブラウザのクッキー削除、システムログの削除だけチェックを外してそれ以外のメニューをすべて実行する。
これはクッキーの削除はCocoaCookiesの方が必要なものだけ削除できて便利だからだし、システムログは何か問題が起きた時に、なにが問題だったかを調べるのに手がかりになることがあるからだ。
ただアーカイブ化された過去のものはまず見ることはないので、削除する。
これらの手順は上記MainMenuとほとんどだぶっているが、これも念のためというくらいの意味。






Cache Outでブラウザキャッシュ、ファビコンキャッシュなどをまとめて削除する
cookieだけはCocoaCookiesでやった方が便利なので置いておく





またCache Outでシステムキャッシュ、ユーザキャッシュ、Swapなどもまとめて削除できる
現在のログだけは万一の時のトラシューのために置いておく



2)これらの操作は再起動を必要とするので必ずここで、再起動をして一度ログイン画面までは起動させておく。
この操作で、削除されたSwapファイル、キャッシュファイルなどが再生成されるので必ず一度ログイン画面までは起動しておくこと。(私の場合自動ログインする設定にはしていない)

その上で再度再起動をかけて、起動画面のグレーのリンゴが出てくる前に
コマンドキー+Sキー
を押し続ける。
これでシングルユーザモード(SUM)に入る。
SUMに入ったら
fsck -fy
とタイプしてenterキーを叩く。
これでディスクの修復ができる。

ただし最近のAppleのTILだったか出典のURLを忘れたのだが、最近のジャーナリングシステムの仕様変更によりマニュアルでfsckをやることはほぼ意味がないそうだ。
確かに最近はエラーの表示が少なく、大抵は
The Volumes appears to be OK
(問題ありませんという意味でしょうな)
が出るようになった。ただたまに
「Task ◯◯はそれが依存するカーネルが発見できない」
というような意味合いのエラーが出るので、調子が悪いMacにはこれを実行する意味はまだあると思う。
エラーが出たら出なくなるまでこの操作を繰り返す。


さらにここで念のために AppleJackを実行しておく。
これはシングルユーザモードで使えるコマンドを簡単な文字列のコマンドで実行できるスクリプト集で、インストーラでインストールしたら使い方は簡単だ。
このSUMで
applejack
とタイプするとAppleJackの待機画面表示になる。
後はそこのナビゲーションの指示に従って実行したいスクリプトのキーを叩くだけでいい。

ちなみに私はaキーを叩いてオートパイロットに任せっきりにしている。
いくつかの作業がここまでのプロセスとダブっているが、それでもこれでやっている。
何も考えなくていいからだ。
それにGUIなどのバックグラウンドプロセスがすべて停止しているSUMで実行するAppleJackのプロセスが一番信頼できるような気がする。
気がするという程度の確度だが、メンテナンスは半分は気のものなので気分的にすっきりする方法でやるのが正解だと思う。

ただしBBSでいただいた情報によると最新OSのLeopardではAppleJackはまだ正常に動いていないそうだ。
上記のように大部分ほかのプロセスとダブっていてゼヒモノのプロセスではないので飛ばしてもいいと思うが、Leopardに対応したらやっておくといい。






SUMでapplejackと叩くだけでAppleJackのこういう待機画面表示が現れる
コマンドのリストがここにすべて書かれているが私はaキーでお手軽にすましている



SUMからぬけ出す時のコマンドは
reboot
でenterキーを叩く。fsckだけで抜ける時にはこちらを使う。
AppleJackを実行後はリブートのコマンドは
rキー
のみでいい。
それで再起動して再びGUIに入る。


3)ここで再び不要なファイルの削除を続ける。まずはcookie。

CocoaCookiesを使ってSafariの不要なcookieを削除しておく。
ただし全削除すると、パスワードを省略してログインできるサイトもいちいちIDやパスワードを要求されるようになって不便だ。

そこで常連のサイトのcookieだけ残して後はすべて削除というような操作を一瞬でできるCocoaCookiesを愛用している。
cookieは無害なのかコマメに削除した方が良いのか人によって意見が分かれるところだが、私はブラウザの挙動に影響するファイルが大量にたまって、しかもそれが見ず知らずの1回覗いたっきりのサイトのものが大部分で、訳が分からなくなっているという状態を好まないので削除することにしている。
cookieがトロイの木馬の偽装の温床にならないかという心配もあって、Macではそういう前例は知らないがWindowsではそういうケースもあったと記憶しているから削除は大メンテナンスの時にする。






CocoaCookiesのようなユーティリティを使ってブラウザのcookieを削除しておく
全削除すると常連サイトでパスワードを要求されたり面倒なのでこのアプリで
お馴染みサイトは残してそれ以外のcookieのみを一気に削除する



4)Monolingualを使って英語と日本語以外のローカライズファイルを削除する。
時々念を入れてYoupi Optimizerも一緒にかける時もある。
これでほぼすべてのローカライズファイルを削除することができる。

最近はオンラインウエアも世界中のローカライズファイルを実装するケースが多くなってきた。
ひとつひとつのファイルの大きさは大したことがないが、20〜30カ国に対応したアプリが数百もインストールされると、積もり積もったそのファイルの合計の大きさはなかなかバカにならない。

初めてMonolingualを使った時には確かディスクスペースが400〜500MBは節約できた。
今ならもっとに違いない。
私の場合は特別多いと思うが、結構なスペースになっていると思うのでたまにかけてみるのも良いと思う。
ただし、注意点は英語のファイルは絶対に削除しないこと。
ローカライズファイルを含まない機能、アプリはすべて死ぬ。
また日本語でOSを動かしている人は日本語ファイルも削除してはいけないことも言うまでもない。






Monolingualはデフォでは主要言語は削除しない設定になっている
イタリア語、フランス語、スウェーデン語などでOSを動かす可能性がないなら削除してしまおう



5)また昨年のintelMacの発表以来、intelのCPUに対応するために多くのアプリはPPC用のバイナリとintel用のバイナリの二つを両方含む「ユニバーサルバイナリ」という構造に対応した。
これはそのアプリをintelに持っていってもそのまま動くのでなかなか便利なシステムなのだが、PPCで動かしている時にはintel用のバイナリはムダだし、逆もムダでしかない。

そこでTrimTheFatを使って不要なバイナリを削除する。
方法はTrimTheFatのウインドウなりアイコンなりに対象のユニバーサルバイナリのアプリをドロップする。
すると不要なバイナリを省いたアプリが元のままのアプリケーション名で現れ、元のままユニバーサルバイナリ状態のアプリケーションが
「アプリ名-U.app」
という名称に書き換えられて残る。
この元の名前の方を起動してみて問題が無いようなら、-Uの名称の方を削除することでユニバーサルバイナリを削除できる。
問題が起きるようだったら、元のままのアプリ名の方を削除して-Uのついた方を名前を元に戻して引き続き使う。これで何もしていないもとの状態に戻せる。






TrimTheFatは起動するとこういうフェイスになる
このシンプルなフェイスにユニバーサルバイナリのアプリをドロップするだけで良い
そうするとこのように何KBスペースを節約できたか表示してくれる





ドロップされたアプリはこのとおり-Uというネームに
変更されたものとオリジナルネームのものの二つになる
-Uがついた方がオリジナルのユニバーサルバイナリのもので
ついていない方が余計なコードが削除されてスリムになった方だ



6)ディスクアクセス権の修正
Locate、Whatis、LaunchServiceデータベースの修正
システム最適化(prebinding)

これらのプロセスは、前はディスクユーティリティで、それ以外はTerminalを起動してコマンドでやっていたが、最近では全部MainMenuでやっている。
理由はお手軽だからだ。

方法はキャプチャーで示した通りMainMenuからプルダウンで

起動ディスクのアクセス権を修復(ディスクユーティリティと同じ機能)
OS9のアクセス権を修復(クラシック環境のデスクトップ再構築と同じ機能)
Spotlightのインデックスを再構築
Locateデータベースを再構築
Whatisデータベースを再構築
LaunchServicesデータベースを再構築
システム最適化(sudo update_prebinding -root /と同じ機能)
最適化をやり直す


以上のメニューを実行する。
Swapやキャッシュファイルの削除などでアクセス権やWhatisなどいろいろ書き変わるようなのでこれらのメニューをいつも最後の締めにする。






MainMenuのメニューアイコンからプルダウンでこれらのメニューを実行
起動ディスクのアクセス権は以前はディスクユーティリティでやっていたが
ひとつで全部できるならこの方がお手軽





こちらはファイル操作などの様々な関連付けのメニュー
Spotlightの再構築は年に一度か半年に一度くらいの頻度で充分
システム最適化はTerminalsudo update_prebinding -root /
というコマンドを打っていたのと同じ機能のようだ
Terminalでは機能が分からなかったがこちらはプロセスを見ることができる





そのプロセスを見ていると「could not」「no need to」という項目がずらりと並ぶ
つまり最近のOSXではあまり意味がないと聞いていたがどうもその通りのようだ



以上のような大メンテナンスをやはり1ヶ月〜2ヶ月に1回実行している。
それ以上の頻度で実行することは、よほど何か特殊なストレスをシステムにかけていない限りおそらくあまり意味がない。
だからそれくらいの頻度でゆったりとやればいいと思う。
ただし半年も1年も全くメンテナンス無しで使っていたら、あちこちに不具合は出てくる筈だ。

以前90日連続起動したままで使うテストをした時も、記録が途絶えて3ヶ月ぶりにメンテナンス手順を実行したが、その時キャッシュファイルクリアやLaunchServicesなどデータベース再構築で異常に時間がかかったことから、やらないとなにがしか問題が起きるのは間違いない。

普段、GUIがクラッシュして強制再起動を余儀なくされたときくらいは、SUMに入ってfsckくらいはやるが、それ以外は全く何もやらない。
しかしこの2ヶ月の定時メンテナンスでこれまでのところシステムは快調に動いている。
ここらが妥当かと思うが、他に「これもやっておいた方が良い」というご意見があれば是非寄せていただきたい。







システムメンテナンスのtips

anchor

もう時間が経っちゃったけどもしTigerを仕事で使っているんだったらOS10.4.11アップデートはしばらく待った方がいいかも

Mac OS X 10.5.1にアップデートしたらはまった - はこべにっき#を見ていて感じたのだけど、先日かけたOS10.4.11アップデートでも同じような問題点を感じた。

Safariを起動しっ放しにして、しばらく他のアプリで作業をしてまたSafariに戻って何かのページを表示しようとすると、無限に近いようなディスクアクセスにはまってしまいそのまま操作不能になる。
結局は強制終了しないといけない。

最初これはSafari固有の問題かと思ったが、長時間のスリープから復帰する時にもやはりかなり長い時間ディスクコンタクトに入ってしまい、画面真っ暗のまま操作を受け付けない。
アプリの切り替えも、頻繁にやっている時にはいいが久しぶりにやるとまた長考に入ってしまいなかなか切り替えられない。

どうもこれは固有のアプリの問題というよりも、システムの問題のような気がする。
システムキャッシュの扱いがかなり変わってしまったようで、やたらディスクに何かを読みに行ってしまう。


上記リンクでは、/tmpのアクセス権の問題を取り上げておられたが、確かにその問題もあるようで、当方でもmdimportなどのプロセスがかなり長時間アクティブになったりという事もみられた。 リンク先追記を見るとこの問題はディスクユーティリティで解決するそうだ。
確かにmdimportの件は改善されたが、Safariの強制終了の問題は解決されない。

どうもこのTigerの最終アップデートとみられていた、OS10.4.11だが、しばらくサポートが続く事を思うとまだアップデートが出そうな予感がする。 次はOS10.4.11.1とでもするのか、すなおにOS10.4.12とするのか知らないが、このままでは仕事では使い物にならない。 仕事でTigerを使っている人はこのアップデートは入れないように・・・って言ってももう遅いか?




mdimportが暴走してCPUがフルアップしてしまう問題は解決したが・・・






システムメンテナンスのtips

anchor

Safari3.0.4での異常なモタリを解消する方法〜途中まとめ、解決したとはいえないが一応の成果は上げられたので(追記あり)

OS10.4.11アップデートをかけて以来、システム全体にもっさり感が出てきて、時々操作をしてから結果が反映されるまでに異常に待たされるということが、たまに起こるようになってしまった。
これもいつも起こるわけではなく常速では結構このアップデートは速いのだが、断続的にディスクコンタクトが起きてその間全く操作を受け付けないということが起きていた。

システムについては残念ながらこれといった対策は見つけられなかった。
キャッシュ、アーカイブログなどをこまめにクリアすること、ディスクユーティリティをかけて起動ディスクのアクセス権を修復する以外にこれといって対策も見つからないし、これも決定的に効果があるわけではない。
しかし改善はする。






ディスクユーティリティをかけると若干ディスクコンタクトが減り
システム全体の反応速度が増す(ような気がする)
抜本的対策ではないと思うが・・・





これまでにライブラリフォルダ、secure.log、darwin関連の
シンボリックリンクなどのアクセス権が修復されている
ただいずれも決定的な要因とも思えないような項目ばかりだ



残念ながらシステム全体のモタリに関しては決定的なアイデアがないのだが、中でも特にモタリ間がひどいSafari3に関してはいくつか対処策があり、そのいくつかはなかなかの成果を上げている。
それでどれが効果があるのかないのかよくわからないのだが、一応調べたもの、試したものを一通り書いておく。
同じような症状を感じている皆さんは、試してみてどれが効果あるか、あるいはないかまた情報を寄せていただけるとうれしい。

とりあえずSafariだ。
こいつが時々フルアップしてCPUもメモリも占拠してしまう。






Safariが時々レインボーボールを延々と表示して
まるでフリーズしたように全く操作を受け付けなくなってしまう
この時にはこのようにCPUもメモリも独占して数分(時に10分以上)待たされる
プロセスは動いているからフリーズしているわけではないということは分かるのだが
これでは仕事にならないので結局強制終了してしまうことになる





終了するとこの通りCPUもメモリもすっきりしてしまう
Safariをなんとかするだけでもこのアップデートのもっさり感はかなり解決されるはず





BBSに「けけ」さんからいただいた情報によるとSafari
システムログに「JavaScript関連の膨大なログを吐き出している」とのこと
この通りまさにConsoleで見ると「安全ではないスクリプト」などのログが見られた
5日間で100MB単位のログを吐いていたので一ヶ月でギガ単位になるに違いない
これがSafariのもっさり感の非常に大きな要因のようだ





この対策も「けけ」さんから情報をいただいた
JavaScriptを切るというのも手だが今どきのweb2.0サイトはどこもJSは使いまくっている
そこでdebugメニューから「Log JavaScript Exceptions」メニューのチェックを外す
debugメニューがない場合はSafariEnhancerSafariStandなどを使ってdebugを表示する



このJavaScriptはどういうサイトを表示するかでその量もかなり違うようだが、いずれにしてもセキュリティが強化されて「安全ではないJavaScriptの接続が試みられた」というログを大量に吐くようになったが、その「安全」の閾値が異常に高いようでほぼ全てのスクリプトが記述される。
これでは遅くなるのは当たり前のような気がする。
この設定はとっとと切ってしまうのが正解だ。

情報をいただいた「けけ」さん、ありがとうございます。


ついでにこのdebugメニューで「ページの戻る、進むの時に使うキャッシュの使用を止める」というメニューがあるのだがこれもトライしてみた。
これもある程度効果があると感じた。






debugメニューで「Use Back/Foward Cache」のチェックを外す
これで大量のキャッシュを吐き出さなくなってディスクコンタクトが減る筈だ
ただしこのチェックは何かの弾みで元に戻ってしまうので頻繁にチェックが必要



これは確かに効果がありそうなのだが、しばらく使っていると勝手にdebugメニューの「Use Back/Foward Cache」のところにチェックが入っていることがある。
だからちょくちょくここを開いてチェックが外れている状態になっているか確認しないといけない。 何とも心もとないデバッグメニューではある。

この対策が無いかググって見たが、これといって見当たらない。何かUNIX的な方法で対処できるのかもしれないが、そこいらを自由自在に操れるほど私に知識がない。
ネラーが「キャッシュフォルダーにロックをかけて書き込みができないようにしてしまえばいいじゃん」なんて書いていたが、勿論そんなことをしてはいけない。ブラウザが不安定になるだけだと思う。
(後日注*一応このTipsも試してみたところ効果があるようだ。これも文末に追記を書いた)


他にも2ちゃんねるやその他でググって見つけたモノも含めて対策をいくつか、効果は保証しない。






「はま」さんより寄せていただいた対策でアップデート後一度はリセットをするというもの
キャッシュや履歴を全てクリアにしてしまうという意味では確かにやってみる意味はあると思う
ただ、私のところではこれはあまり関係なかったしキャッシュを使わない設定も元に戻ってしまう





SIMBLのバージョンを最新のものに再インストールし直すという対策
SIMBLやInputManagerはなかなか微妙なのでアップデートするのは意味があると思う
私のところでは問題は改善されなかったが





システム環境設定/ネットワークに入って「IPv6」を「切」に設定するというもの
これもネラーのネタだが根拠が全く分からないし効果も感じられなかった
しかし現状使っているわけでもなく余計な機能は切っておくという意味はあるかも



どれが功を奏したか一応Safariに関してはそこそこの速度で動いている。
決して前よりも高速になったとはいえないが、一応の線までは来た。
しかしやはりアプリをどんどん切り替えて使っていると時々ディスクアクセスが始まってしまい、そのまま数分待たされてしまう。

特に他の作業をやっていてSafariに切り替える時が確率的にこの現象は起きやすい。
原因はやはりSwapが大量に作られていることと関係があると思う。
Swapが増えるピッチは明らかにOS10.4.10以前とは変わったので、ここいらの仮想メモリの扱い方が変わったのが一番の問題だと思う。
一番の対策は、いくつものアプリを常に起動しっぱなしで使うことを止めて、必要最低限のアプリだけを起動して、他のなにかを起動する時には要らない何かを終了するなど細かい操作でメモリを節約する・・・・これが一番の対策のような気がする。

心許ないまとめだが、一応途中経過ということで・・・




<追記>

Safariはやや改善したと思われるもののシステム自体の動作改善ははなはだ芳しくないと書いたが、この際全て試してみようということで、BBSに「はま」さんから寄せられていた
「システムがディスクアクセスでもたるのを防ぐためにSpotlightをリセットする」
というTipsも試してみることにした。

最初の時にmdimportのプロセスが動作しっぱなしになっていたことは、2007 年 11 月 19 日の記事でも書いた。この時はこれはディスクユーティリティをかけることで対処したが、やはりアップデート後は一度はSpotlightをリセットした方が良いのかもしれない。
これも確たる根拠はないが、リセット後ほぼ一両日経つ現在、さほど待ち時間無しにシステムが動いているので、このアップデートはかけた後大メンテナンスの手順を全て踏んだ方が良いということなのかもしれない。

SpotlightをリセットするコマンドなどはUNIXコマンドのページなどにも解説したが、ここでは簡単にMainMenuを使ってやってしまった。
特に不具合が起きていない定時メンテナンスの場合はこれで充分だ。






SpotlightのリセットをMainMenuを使って実行
この後メタデータの再構築に2〜4時間はCPUがフルアップするが
その後はこれまでのところ特に問題なく動作している






<さらに後日追記>

さらに2ちゃんねるで拾ってきた
Safariのキャッシュフォルダにロックをかけてしまえばキャッシュの上書きができなくなる」
というTipsも一応検証してみた。
すると確かにこれでディスクアクセスが無くなった。
debugメニューで「Back/Fowardキャッシュを使う」のチェックを外しているのだが、この設定だけではしばらくSafariを使っていると設定が元に戻ってしまう。
このメニューではキャッシュを禁止することは完全にはできないようだ。

そこで
"~/Library/Caches/Safari/"
にあるSafariのキャッシュフォルダーをアクセス禁止にしてしまった。方法はこのフォルダを選択して
コマンド+iキー
で「情報を見る」タグを開いてアクセス権の設定で
「アクセス不可」
にしてしまう。
念のためにここでロックもかけてしまう。

こういうことをやるとdebugメニューでキャッシュ書き出しを完全に禁止できない以上、ブラウザの動作が不安定になって場合によってはクラッシュなどの原因になるのではないかと思っていたが、今のところそういうこともないようだ。
見直したぞ!ネラー!

これは誰にでもお勧めできるような方法ではないが、私のところでは一定の成果を上げている。
なんでこれがうまくいくのか私も半信半疑だが、うまくいくようなのでしばらくこのまま様子を見る。






Safariのキャッシュフォルダーはホームフォルダのライブラリの中にある
ここにロックをかけてさらにアクセス権の設定で「アクセス不可」にしてしまう





するとしばらくSafariを使ってもキャッシュ削除をしても
キャッシュフォルダーの中身は空っぽだ・・・当たり前だが
こんなことでSafariが高速化できる・・・
なぜうまくいくのかよくわからないが・・・



anchor

Safariのキャッシュ生成を禁止する設定〜これでSafariの虹色ボールを防げる・・・ところまではいかなかったが少し効果はあった

Safari3.0.4での異常なモタリを解消する方法〜途中まとめの追記で一応、Safariのキャッシュの書き出しを禁止する方法としてdebugメニューから「進む、戻る/キャッシュを使う」という設定のチェックを外すということを書いた。
これでも一時的には対処できるが、しばらく使っているとまた勝手に設定が入ってしまうので時々開いてチェックを外さなくてはいけない。

これは不便だ。
そこでこれに関する設定を探していたら、おなじdebugメニューの中に
「Show Caches Windows」
というメニューがあった。ここを開くとこのウインドウに
「webコアキャッシュを使わない」
という設定がある。このチェックを外して各項目のキャッシュがゼロになるまで「empty」と書いたボタンをクリックする。
これで一応、webキャッシュは溜め込まないようになる。

残念ながら、セッションごとにここの設定も元に戻ってしまうので、毎回Safariを起動するごとに設定しないといけないのだが、いつのまにか勝手に元に戻ってしまうよりはましだろう。

もうひとつ問題はここの設定をしていても一日Safariを使っていると結局レインボーボールが止まらなくなってSafariを強制終了しないといけなくなるのはおんなじだということだ。

この症状はメモリーリークに似ているような気がする。
確信はないのだが、まだこのSafari3とOS10.4.11は修正すべき点があるように思う。






Safariのdebugメニューから「Show Caches Window」というメニューを開く
その中の「Disable WebCore Caches」というメニューのチェックを入れて
それぞれのキャッシュがゼロになるまで「Empty」と書いてあるボタンをクリックする






システムメンテナンスのtips

anchor

「全ては無駄であった。あらゆる犠牲もあらゆる労苦も無駄だった。」〜A.ヒトラー『我が闘争』より・・・じゃないがSpotlightクラッシュと格闘した二日間だった

先日、『Safari3.0.4での異常なモタリを解消する方法〜途中まとめ、解決したとはいえないが一応の成果は上げられたので(追記あり) 』というまとめで、現象的にはSafariの異常なモタリの解消法についていくつか話題になっているものを挙げたが、現状この問題は多少改善しただけで、解決していない。

結局この問題は「Safari3がちょっと調子が悪い」というような局所的な問題ではなく、OS10.4.11のアップデータの問題でアプリとシステムの仮想メモリの扱いに不整合が起きて、異常なディスクコンタクトが起きているような、それがたまたまSafariに集中的に出ているだけでシステムそのものの問題ではないかという気がしている。

ただ、このアップデータをかけた人はみんな問題を起こしているわけでなく、問題が起きている人といない人がいるようだ。
それが何か局所的な手順で解消できないかと思わされる部分だ。

前回の記事でも最初に「Spotlightのインデックスを再構築」をMainMenuを使ってやってみたのだが、「Spotlightを初期化するとこのモタリが解消する」という記事を複数の場所で見かけたので、もう一度トライすることにした。

片方でアップル - サポート - ダウンロード - Mac OS X 10.4.10 Combo Update (PPC)でOS10.4.10のコンボアップデートを入手、もし今回のトライが失敗に終わった場合は、システムを再インストールしてこのアップデータをかける・・・つまりOS10.4.10にバージョンダウンするということも視野に入れてスタンバイした。

この手許のiBookG4はまだ半年かそこらは第一線機だろうし、intelMacに移行した後もしばらくはBack up機として使い続けることになるだろうから、この虹色ボールが出て動かなくなるというんじゃ使い物にならない。
今回はこうした非常の決意を持って臨むテストなので、徹底的にやる。

なのでMainMenuを使わずにこちらの「メタデータを初期化するコマンド」という記事の手順で全てのインデックスを初期化した。






同じことかもしれないがMainMenuの「Spotlightのインデックスを再構築」
を使わずにコマンドで全てのボリュームのインデックスを初期化した





それから一昼夜この状態でずっとCPUがフルアップしている
しかも赤い領域はシステムが使用している領域だが
システムがほとんどこのプロセスを占拠していることが判る
この時点でおかしいと気がつくべきだった



初期化をしてSpotlightが無反応になってしまった。 右上隅のSpotlightのアイコンをクリックしても検索ウインドウが開かない。
元々こちらの検索ウインドウは滅多に使わないのでそれはどちらでも良いのだが、キャプチャーのようにCPUがフルアップしたまま一昼夜たっても全く状況が変わらない。
このままではシステムがモタリまくりだし、いつもはSpotlightの初期化の後のインデックス再構築は数十分から2時間程度で大体終了する。
いくら何でも丸一日は時間がかかり過ぎだと判断して、作業を中断、再度初期化することにした。

それで「Spotlightがちゃんと動いていない。(mds、lsregisterが動いていない)」というこちらのTipsをここで実行することにした。
具体的には
cd /
でルートボリュームの第1階層に移動して
sudo rm /mds-crash-state
というコマンドで、mds-crash-stateというメタデータサーバのクラッシュ情報ファイルを削除することでmdsなどがちゃんと動くようになるという方法に期待をかけた。
私の場合はメンドクサイので時間はかかるが、
sudo find / -name "mds-crash-state" -delete
というようなコマンドも使って全てのボリュームからこの名前のファイルを全て削除した。

しかしこれでも状態が変わらないので、さらに
cd /System/Library/Frameworks/ApplicationServices.framework/ Frameworks/LaunchServices.framework/Support
でこのパスに移動して、
./lsregister -kill -r -domain system -domain local -domain user
というコマンドを実行して「mdimport」を初期化するという方法を実行した。






App Stopでプロセスを見ると「mds」「LAServer」「configd」がプロセスを占めており
一応メタデータを生成しているかのような感じだが直上のキャプチャーのように
ディスクアクセスが全く無く、ちゃんと動いているように見えない





そこでmdsなどが動いていない場合のTipsでmdsのクラッシュ情報ファイルを削除
sudo mdutil -E /コマンドで再びインデックスを初期化して再構築をリスタートさせた
ただしここで「インデックスファイルは見つからなかった」という
エラー表示が出ているのが気になったところだ





そこでさらにmdimportを初期化するコマンドも実行
リンク先のTipsのページでは私は違うパスでないとこのコマンドは
動かないと書いているが今回はこのデフォルトのパスでないと動かなかった
ここでもエラー表示が同じように出ている





Spotlightの検索窓が相変わらず開かないしエラー表示も消えない
なのでこちらの「起動ボリューム以外のボリュームの中身の索引が不完全」
というTipsに挙げた「JapaneseAnalysis」のメタデータ関連ファイルを削除した
"~/Library/Preferences/com.apple.JapaneseAnalysis/AppleContextualKKC.index/"の中の
"AdaptiveMap"、"InputHistory.plist"
の二つを削除する





相変わらずエラー表意はでるがこのまま様子を見ることにした





しばらく走らせてMainMenuでリセットするとやはりエラー表示だが
今度は「リセットできない」という内容で「インデックスが見つからない」ではない
こういうものなのかもしれない





およそ2時間CPUはフルアップしていたが今度は何をしても
振り切った状態のままではないしMenuMeterの表示も「真っ赤」ではない
何が良かったのか判らないが今度は結果的には成功したのだが・・・



ということで今度はSpotlightインデックス再構築には成功した。
一度にやってしまったのでどのTipsが成功につながったのか判らないが、どれかが良かったのだろう。
ただ問題は、Spotlightの検索窓は相変わらず開かない。
メタデータ検索は問題なく動いている。
それだけなら別に気にしないのだが、一両日テストしてみて結局Safariを一日起動して使っているとやはりSwapは3GBに増えてしまうし、やはり虹色ボールが出てきてくるくる回り始める。
結局今回のトライを始める前と比べて何も改善されていないことが判った。

この2日間の死闘は一体何だったのか、「全てが無駄だった」というプロイセン帝国崩壊を目の当たりにしたヒトラーの心境はかくのごとしかというほどの脱力感だ。

デスクトップの「OS10.4.10アップデータ」が強烈に視界の中でアピールしている。
真剣にバージョンダウンしてしまおうか・・・・


<最終結論>

結局Spotlightのメニューの検索ウインドウは使えないままそれでもファイル検索自体はちゃんと動いているようなので、そのまま数日使っていた。
そしたらいつの間に現れたのか、起動ボリュームの第一階層に
mds-crash-state
という本来不可視である筈のファイルが見えている。
どうやらこれを削除する
sudo rm /mds-crash-state
というコマンドがなぜか上手く動いていなかったようだ。

このファイルを削除したらSpotlightのメニューバーアイコンからの検索も何ら問題なく動いている。
結局何が原因でそうなったのかよくわからないが、この問題はこのようにして解決した。
そしてメニューバーアイコンからの検索ウインドウプルダウンが利かない時はやはり
mds-crash-state
の削除が有効だということだ。




2007 年 12 月 20 日


anchor

「全ては無駄だった・・・」なんて大仰な慨嘆調の文章を書いてしまったが、「そういう仕様です」ということ?〜Spotlight再構築ですぐにインデックスを作り始めないのは「そういう仕様」らしい

ここ数日、ちょっともろもろ動作が重くなって来ているように感じたので、ルーティンのメンテナンス。 その時にMainMenu
Spotlightのインデックスを再構築」
を実行、Spotlightもリフレッシュすることにした。
そうするとまたここの
「全ては無駄であった。あらゆる犠牲もあらゆる労苦も無駄だった。」~A.ヒトラー『我が闘争』より・・・じゃないがSpotlightクラッシュと格闘した二日間だった
で取り上げた同じ症状が再現。
mds、mdimporter、LAServerなどが動いていないようなので、一通りのメンテナンス手順と、このリンク先の対策をやってみた。
しかしやはり動いていない。

その対策を散々やっても、結局このリンク先と全く同じ症状を再現した。
どうにもならなかったので、しばらく放置して再起動。
するとあっさりSpotlightの検索窓が開くようになり、mdsなどのプロセスも快調にメタデータを読みにいっているようだ。

要するにこの問題の解決法は、CUIコマンドなどを使ってバタバタと怪しいファイルを初期化するようなことをしないで、一度深呼吸して再起動する・・・それだけで良いようだ。
不思議だ。
以前はmdutilコマンドでSpotlightを初期化するだけですぐに読み込みが始まってmds等がフルアップしていたが、今の仕様は一度再起動しないといけないようだ。

そういうことなら仕方がないが、そういうふうに変わったというお断りを一言欲しいなぁ。
おかげでシステムが壊れたのかと思って、その検証にのべで数日費やしてしまったではないか!
しかも大袈裟な慨嘆口調の文章を書いてしまったオレってバカみたい・・・
  _, ._
( ゚ Д゚)






mds-crash-stateの削除など対策を講じるもmdsなどの
Spotlightインデックス生成のプロセスはうんともすんとも反応せず
またSpotlightが壊れてしまったのか・・・・





と思いきや、一度深呼吸して再起動をするとあっさり復活してしまった
メニューバー右端のSpotlightアイコンもあっさり開いて検索窓を表示
この「一息深呼吸」が対策のコツなのかも・・・



2008 年 1 月 28 日










Previous Topへ Next





site statistics