シャットダウンが遅くなってしまった

みなさま、はじめまして。初めてこの場所で質問するUmeKAMAと申します。

よろしくお願いします。


みなさまに教えていただきたいのは、Snow LeopardのShut-downについてです。

先週金曜日にSnow Leopardを所謂クリーン・インストールで、

MacBook初期型(Core Duoモデル, 2Gメモリ、500G HD)にインストールしました。

インストール直後、シャットダウンは本当に一瞬で大変快適でした。

しかし、10日経過した現在では「終了」を選んだ後に歯車が回り始め、

30秒以上かかって、やっとシャットダウンするまで遅くなってしまいました。

試しに起動直後にシャットダウンしてみても結果は同じです。

一応、アクセス権の修復やセーフブートなども実行しましたが、

インストール直後のような瞬時終了には戻りませんでした。


実用上問題はあまりないのですが、なぜシャットダウンにこのように

時間がかかるようになったのか原因がわからず、困っています。

投稿日 2009/09/05 22:22

返信
返信: 52

2009/09/06 07:45 UmeKAMA への返信

UmeKAMA さんによる書き込み:


ところで、ふと気になったのですが、みなさまのMacのシャットダウンのスピードはどのくらいなのでしょうか?私のMacBookシャットダウンまで約30秒というのは実用上は問題がないと思う範囲 (30秒でもLeopardのときよりも早い)なので、もしかしてこのくらいのスピードが普通で、一瞬でシャットダウンしてたインストール直後のほうが異常なのでは?となんだか疑心暗鬼になってきました。


試してみました。まず、先日、10分を経過してもシステムが終了しなかったカミさんの Mac Pro (Dual-Core Intel Xeon 5100/2.66 GHz/2 GB RAM/250 GB HDD) を試してみようとも思いましたが、Pages で大量のファイルを開いて作業中だったので、まさか「いま、実験させて!」なんてとても言い出せず、断念しました (^^;)。


で、カミさんの MacBook Air で実験したところ、なんと 4.38” で終了! もう1度試してみましたが、次も 4.78”。


次に自分の 17" MacBook Pro で試しました。MacBook Air の時もそうですが、全てのアプリを終了して、Finder だけにして、そこで電源ボタンを押して「システム終了」を押した瞬間にストップウォッチを押しました。


やはり、“マーフィーの法則”ですね。なんと、9.91” で終了してしまいました! ったく...(^^;)!


今回のテストは条件を同じくするために、起動直後に、全ての起動項目に入っていて起動していたアプリを終了してからテストしました。つまり、実質的には何の作業もしない状態でシステム終了したわけです。想像するに、実際に何時間も作業をした後のシステム終了の場合には、大量のウィンドウの位置情報とか、保存したことになっているけれども、実際にはキャッシュに入っていただけの情報をディスクに書きだす作業とかがあって、相当の時間が掛かるのではないかと思います。


それにしても、再起動直後のシステム終了は驚くほど速かったですね...(^^;)。


--------------------

Apple 17" MacBook Pro (Intel Core 2 Duo T7600/2.33 GHz/3 GB RAM/500 GB HDD)

Mac OS X 10.6 (Build 10A432) [Snow Leopard]

2009/09/06 07:51 ni_ki への返信

ni_ki さんによる書き込み:

しい坊 さんによる書き込み:


試しましたが、「PAE」でも「npvhash」でも何もヒットしません...。

私の所だと、MacBook ProもMac miini 1.66GHzCore Duoでも有るのですが。

気を取り直して(ダメダメを書いておいて勝手に気を取り直すなと言われそうですが)

「09/09/06 20:09:09kernelDarwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386」

こんな感じの表示は、無いでしょうか?


「Darwin」で検索してみました。system.log では何もヒットしませんでしたが、「すべてのメッセージ」では2件ヒットしました。ただし、これが実際にどこのログなのかを判断する方法が分かりません。内容は以下の通りです:


2009.09.06. 23:12:10 kernel Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386


2009.09.06. 23:22:46 kernel Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386


これで何か分かりますか?


--------------------

Apple 17" MacBook Pro (Intel Core 2 Duo T7600/2.33 GHz/3 GB RAM/500 GB HDD)

Mac OS X 10.6 (Build 10A432) [Snow Leopard]

2009/09/06 08:04 HAL への返信

HALさま。


教えていただいたコマンドをTerminal.appから実行し、シャットダウンしてみました。シャットダウン1度目は今までのシャットダウンのプロセスと異なり、すぐに青い画面と歯車クルクルに移行せず、デスクトップピクチャの雪豹さんと数十秒睨めっこ。しかし2度目からは以前のシャットダウンスピードに戻りました!! 起動直後にシャットダウンすると、以前は30秒程度かかっていたものが5秒以内にコンピュータが停止するようになりました。つまり、原因はアクセス権およびCan't create kext cache under / - owner not root.だったようです。30秒は気にするほどのことでも無い気がしましたが、実際にシャットダウンが早くなると、本当に気持ちが良いです。すばらしい情報、誠にありがとうございました。以下、シャットダウンのスピードが元に戻った後のログです。"hidd died. Reestablishing connection"について調べてみましたが、よくわかりませんでした。


Sep 6 23:34:35 com.apple.launchd.peruser.501[106] ([0x0-0x10010].com.apple.Console[156]): Exited: Killed

Sep 6 23:34:36 loginwindow[25]: DEAD_PROCESS: 25 console

Sep 6 23:34:36 shutdown[163]: halt by XXXXi:

Sep 6 23:34:36 shutdown[163]: SHUTDOWN_TIME: 1252247676 146034

Sep 6 23:34:36 mDNSResponder[24]: mDNSResponder mDNSResponder-212.1 (Jul 24 2009 22:34:14) stopping

Sep 6 23:34:36 WindowServer[64]: hidd died. Reestablishing connection.

Sep 6 23:34:36 WindowServer[64]: bootstrap_look_ip failed: Unknown service name



しかし、対処療法的には問題解決なんですが、なんでアクセス権がすべてRead&Writeになっていたのでしょう?こんな風にアクセス権を変更するアプリケーションってありますかね?アクセス権がおかしくなった原因を究明しなければなんとなく腑に落ちません。。。


ni_kiさま、しい坊さま、xyさま。いろいろ教えてくださりありがとうございました。Console.appの使い方もみなさまのおかげでなんとなくわかりました。今後トラブルに遭った際には最初にlogを確認して、googleで検索し自分なりに調べてみようと思います。

2009/09/06 08:41 UmeKAMA への返信

対処療法的には問題解決なんですが、なんでアクセス権がすべてRead&Writeになっていたのでしょう?こんな風にアクセス権を変更するアプリケーションってありますかね?


今システムをインストールしているパーティションの履歴のようなものはわかりますか?

例えば、購入時にプリインストールされたシステム (10.4.8) をそのまま使い続けその後10.5に上書きアップグレード、その後10.6へのアップグレードはクリーンインストールした10.6に移行アシスタントでTime Machineからデータを移行した・・・みたいな?

どこかの段階でアクセス権がくるったまま、今の段になって症状として表に出てきた・・・のかな。

クリーンインストールって最初の投稿に書いてありましたね。失礼いたしました。

となると、何かのインストーラが悪さしたのかもしれませんね。

ログを遡って、Can't create kext cacheが何時から出るようになったのかと、ディスクユーティリティのログを確認してアクセス権の修復時にLibraryとかの修復のログが残っていたりしたらその前にインストールした何かがあやしいのである程度原因がしぼれるかもしれません。

なんにせよ今回わかったのは、アクセス権の修復は、システムボリューム自身のアクセス権は修復してくれないってことですね。これは結構な落とし穴・・・かも。


なんにせよ解決してなによりです (^^)

念のためきちんとアクセス権が正しく設定されているか、ターミナルから

ls -la /.

として、出力の二番目の行 ./ のアクセス権がどのようになっているかを一応確認しておいてください。

drwxr-xr-x ** root admin **** * ** **:** ./

となっていればOKです。


追記:

Snow Leopardに対応したATOK 2008やASM (Application Switcher Menu)をインストールした後くらいからシャットダウンが突然、遅くなった気がします。


ATOKってアクセス権がらみのトラブルが多い印象なので怪しいかも・・・

もし興味があれば、ATOK 2008をインストールし直してみてアクセス権が変わるかどうかを確認してみてもいいかも・・・。

2009/09/06 08:47 UmeKAMA への返信

> なんでアクセス権がすべてRead&Writeになっていたのでしょう?こんな風にアクセス権を変更するアプリケーションってありますかね?


ボリュームのルートのアクセス権がこのように変わってしまうというのはかなり危険なことです。考えられる原因は、悪質なウィルス,出来損ないのソフトによる悪質な影響,アップデートのプロセスが正常に進行しなかった,などおぞましいものばかりです。everyone にread, write というのは、悪質なウィルスのようなソフトがでたらめにアクセス権を変更するときに使うものです。このようなアクセス権になっていれば,無関係なものが更に悪質なものを書き込んだり,大事なファイルを好きなように変更できるからです。

もしこんなふうにアクセス権が変更されてしまったとしたら,私なら,ディスクを初期化してOSのクリーンインストール,アプリも最初から全部クリーンインストールです。

2009/09/06 09:07 HAL への返信

HALさま。


今、Snow LeopardをインストールしているPartitionの履歴は以下の通りです。


まずSeagate ST9500420ASというハードディスクを購入し、FirewireでMacBookと接続し、GUIDパーティションでフォーマット。その後、Snow Leopardをインストール。ST9500420ASには何もデーターは入っていないので当然、クリーンインストールになります。


このST9500420ASをMacBookに装着し、iLife 09, iWork 09をインストールしソフトウェアアップデートを実行。その後、以下のアプリケーションのSnow Leopard対応版を順次インストールしていきました。これらアプリケーションはインストールディスクがあるものはそこからインストールし、その後SnowLeopard対応アップデータを実行する。ディスクがないものは、dmgやzipファイルをベンダーの公式サイトから入手し、それをインストールしました。現在私のMacBookにインストールされているソフトウェアは以下の通りです(インストールの順序は忘れました)


Acorn

AdobePhotoshop Elements 6 for Mac

AppFresh

AppleCleaner

Art Text 2

ATOK 2008 for Mac

CandyBar

CDダイレクトプリント

ChronoSync 4

Comic Life

DMG Converter

Dropbox

EIJRO Viewer

Bento 2

Bookpedia 4

Firefox

Fleax

Google Earth

Google Picasa

GraphicConverter

IceClean

Img2icns

Jedit X2

Justlooking

LaunchBar 4

Phenix Slides

PhotoMechanic 4

Picturesque

Mactracker

Microsoft Office 2008

Mindjet Mindmanager 7

MacJournal

MoneyDance

Mplayer OSX extended

NetNewsWire

NoteTaker

NovaMind 4 Pro

OmniDiskSweeper

OmniFocus

OmniGraffle 5 Pro

OmniOutliner 3 Pro

Realplayer 11

Skype

Stationery Pack

Swift Publisher 2

The Hit List

The Unarchiver

Things

Thinkertool

Timer Utility

Toast 8

Transmission

Tree

UnRarX

VLC

VMWare Fusion

Wallet 3

XMind 3

Yahoo! Messenger 3

Yep


プラグイン・ドライバ系では、

ASM

Adobe Flash

Flip4Mac

DivX7

GutenprintPrinterDrivers2.0


PerianとGrowlはいずれ入れるつもりですが、なんとなくまだ入れていません。


こんな感じです。Snow Leopardインストール直前にTimeMachineとChronoSyncでバックアップを2つ取っており、Apple MailやBento, MacJournalなどのデータはChronoSyncでカーボンコピーしたLeopard起動可能なハードディスクのApplication supportフォルダ内にある該当データをコピーしました。


個人的にはボリュームのアクセス権を変更するほど悪質なものはないと思うのですが、、

怪しいのはATOK2008なのかなぁ、、、シャットダウンが遅くなったと私がはっきり認識したのもATOKインストールの前後ですし。明日、ATOKを削除→再インストールして、アクセス権がどうなるか調べて、またここで報告いたします。


最後にTerminalではきちんとdrwxr-xr-x ** root admin **** * ** **:** ./なっていました。安心しました。ありがとうございます。


はにさま。


なんだか怖い話ですね。ウィルスとは考えたくないというか、思い当たる節もありませんし、Activity Monitorにもそれらしいプロセスはありません。上記の通り、私のクリーンインストール作業は大変なので、アクセス権変更の原因が特定できないと、もう一度クリーンインストール!というのは正直、億劫です。今回皆様に助けていただいたシャットダウン遅延問題以外にも、アイコンが突然透明!になったり(再起動で元に戻りました)、SafariのTopsiteの表示が乱れたりとなんだか挙動が変ですし、問題がたくさん起きているらしいFamily Packですので、少し私も心配になってきました。実際には大半の問題は今後Appleからリリースされるであろう10.6.1などで解決すると思いますが、ちょっと不安。とりあえず、明日のATOKを削除→再インストールしてから考えます。ご助言、誠にありがとうございます。

2009/09/06 17:27 UmeKAMA への返信

個人的にはボリュームのアクセス権を変更するほど悪質なものはないと思うのですが、、


OSはバージョンによって微妙にアクセス権が変わっていて、古いインストーラの場合それが考慮されずに大事なフォルダのアクセス権を変えてしまうことがあります。

# 私のところではKensingtonのMouseWorks (2006年が最終更新日) が /Library/PreferencePanes のアクセス権を狂わせます


ATOKが白だった場合、とりあえずドラッグアンドドロップでインストールするタイプのアプリケーションは候補から外していいと思います。

最近アップグレードしていない古いインストーラをつかうアプリケーションやドライバが一番あやしいです。

# 個人的にはVISEの古いインストーラがかなりたちが悪いと感じています。

古そうなものから順にアテをつけていくといいかもしれません。

あと、ディスクユーティリティ>ウインドウ>ログを表示 でこれまでの履歴が確認できます。

アクセス権の修復をこれまでに何度かしているのであれば、過去に遡って怪しい修復履歴がないかを確認してみてください。


インストーラが犯人である確証はないので、徒労に終わる可能性もあります。

なので無理はしなくてもいいので興味があれば調べてみてください。

# 原因がインストーラ以外の方がやっかいなので、できればこれで解決してくれれば・・・とも思います。


あと、今のシステムをいろいろいじって状態を悪くしても困るでしょうから、外付けHDD等に別にシステムを用意できるならそちらで同じようにセットアップを進めていってどの段階でアクセス権が狂うのか見ていく方がいいかもしれません。

2009/09/06 21:47 xy への返信

xy さんによる書き込み:

しい坊 による書き込み:


それにしても、再起動直後のシステム終了は驚くほど速かったですね...(^^;)。


そりゃ、変更が発生してませんからね。


先ほど、一晩シャットダウンしなかった自分の 17" MacBook Pro をシステム終了してみました。ずっと使い続けてきていたのに、今回は 30.61” で終了しました。あら...。変更は発生していたはずなのに。


で、カミさんが出かけるので、カミさんの Mac Pro (Dual-Core Intel Xeon 5100/2.66 GHz/2 GB RAM/250 GB HDD) のシステムを終了させてもらいました。カミさんの Mac Pro も数日間使いっ放しで変更データは相当溜まっていたはずです。とりあえず、全てのアプリを終了して、Finder だけの状態にして、「せ〜の!」でシステム終了のボタンを押しました。なんと、29.61” で終了しました! 先日は 15分経っても歯車アイコンが回りっ放しだったのがウソのようです!


さらに、その Mac Pro を起動させて、デスクトップを表示させました。起動項目にあって自動的に立ち上がったいくつかのアプリが立ち上がるのを待って、それらも個別に終了させ、また先ほどと同じ Finder だけの画面にして、もう1度システム終了を試みました。今度は変更点はほとんどないはずです。30秒掛かっていたのがもっと短くなるか? 実際にやってみたところ、今度はシステム終了に 58.13” 掛かってしまいました...。


どういうことなんでしょうね?


--------------------

Apple 17" MacBook Pro (Intel Core 2 Duo T7600/2.33 GHz/3 GB RAM/500 GB HDD)

Mac OS X 10.6 (Build 10A432) [Snow Leopard]

2009/09/06 22:00 しい坊 への返信

しい坊 による書き込み:



どういうことなんでしょうね?

まず、OSは抱えている仕事がいっぱいありますから,表面上の挙動が同じになることはあり得ないです。

数十回、試行して統計処理するなり、それこそ詳細なログをとって解析するなりしないと。


ディスクへの書き出しを保留するのはかなりのリスクになるので、フラッシュは、チャンスを見て実行されているはず。

シャットダウン時に実行するのは最もリスクが大きいので、可能な限り避けると思われる。

フラッシュは、その内容から見て、又はプログラム処理であることから見て、連続的ではなく、間欠的になるはず。従って、時系列で常に同じ挙動になることはありえない。また、OSの環境ファイル関係、設定ファイル関係、動作状況を記憶するファイル等の更新もあるでしょうし。



PS:類例

ファイルを一定時間毎に自動更新する機能付きのアプリケーションソフト。

2009/09/07 02:18 しい坊 への返信

.

しい坊 さんによる書き込み:


2009.09.06. 23:12:10 kernel Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386


2009.09.06. 23:22:46 kernel Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386

これで何か分かりますか?

私の所では、この行か数行上からが、起動時のlogです。私の所の、起動時のlogを数行ほど、記載致します。


09/09/07 17:47:47kernelnpvhash=4095

09/09/07 17:47:47kernelPAE enabled

09/09/07 17:47:47kernel64 bit mode enabled

09/09/07 17:47:47kernelDarwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386

09/09/07 17:47:47kernelvm_page_bootstrap: 901412 free pages and 81628 wired pages

09/09/07 17:47:47kernelstandard timeslicing quantum is 10000 us

09/09/07 17:47:47kernelmig_table_max_displ = 73


電源を切ってから2分も時間を空ければ、その間 のlogが記録されなくなるので、Shutdown時のlogか起動時のlogか区別が付けやすくなります。

ちなみに、kernelnpvhash=4095のすぐ上の行に記録されているlogは下記です。


09/09/07 17:45:44kernelKext unloading is disabled (com.bresink.driver.BRESINKx86Monitoring).


Temperature Monitorと言う温度表示アプリケーションの「ドライバを終了している」と言う内容だと思っています。

2009/09/07 05:17 HAL への返信

みなさま。


昨日は本当にありがとうございました。おかげさまで俊敏なシャットダウンを楽しんでおります。


さて、ディスクのアクセス権がATOKによって変更されたのでは?という疑惑についてですが、結論から申し上げるとやはりATOKが犯人でした。より正確にはATOK 2008用郵便辞書アップデータ (a21y0906.dmg)がアクセス権書き換えの犯人です。


経過説明を致します。まず、Snow Leopardがインストールされ、ディスクのアクセス権も正常かつシャットダウンも早いMacBookにATOK 2008を正規インストールディスクから入れたところ、アクセス権は正常でした。シャットダウンもスムースです。ところが、ATOK 2008用アップデータ (a21y0906.dmg)をあてるとアクセス権がすべて「読み・書き」に変わり、スタートアップおよびシャットダウンが遅くなります。Console.appのログにも"Can't create kext cache under / - owner not root.”の記述が復活し、シャットダウン時にはkext casheを何度も作ろうとしては失敗し、結果として何十秒余計に時間がかかるようになりました。


ATOK 2008自体はHALさまにお教えいただいたアクセス権を正常に戻すターミナルコマンドを打った後でも正常に動いています。すべて「読み・書き」というアクセス権である必要はないみたいです。


ATOK 2008をアップデートしてSnow Leopardを運用している人はかなりたくさんいるはずですが、この不具合は私の環境だけで起こっているものなのでしょうか?ATOK 2008を最新版にしてSnow Leopardで運用されている方がいらっしゃいましたら、アクセス権に不具合が起きてないか教えていただけると、ATOKユーザーすべてにとって有益だと思いますので、よろしくお願いいたします。


それにしてもPowerBook 1400csの時代からATOKには泣かされてきましたが、ここでも不具合がでるとは。定額制ATOKへの移行を考えていましたが再考する必要がありそうです。ATOK2009ユーザーにもアップデータが出ていますが、同じ不具合がないように祈るばかりです。


明日、Justsystemに電話してみます。


情報を正確なものにアップデート

2009/09/07 04:41 UmeKAMA への返信

検証作業おつかれさまでした m(_ _)m 原因がはっきりして一安心です (^^)


結論から申し上げるとやはりATOKが犯人でした。より正確にはATOK 2008をSnow Leopardに対応させるアップデータがアクセス権書き換えの犯人です。


ATOKは前科があるので怪しいとは思いましたが、よりによって最近出たばかりのアップデータが犯人とはトホホですね (^^;


ATOK 2008をアップデートしてSnow Leopardを運用している人はかなりたくさんいるはずですが、この不具合は私の環境だけで起こっているものなのでしょうか?


シャットダウンにかかる時間が10秒だったのが30秒になっても気にしないという人も多いのではないでしょうか。疑問に思わなければログの確認もしないでしょうし、気づいていないだけのように思います。

どの環境でもアクセス権が変わるのか、環境依存なのかも気になるところなので他の方からの報告も欲しいですね。

2009/09/07 06:00 UmeKAMA への返信

たまたま、まっさらなHDDにクリーンインストールしたSnow Leopardがあったので、ATOK2009をインストールする前に2008をインストールしてみました。



ATOK本体をインストール後、アップデータ(at21up3.dmg)を当てた後、ともに、私の環境ではディスクのアクセス権が変更されることはありませんでしたよ。



追記)a21y0906.dmg は、Snow Leopard対応版アップデータでなく、郵便番号辞書アップデータですね。これをインストールしたらディスクのオーナーが自分に変わってしまいます。確かにシャットダウンが遅くなりました。ご注意を。



さらに追記)OSの素の状態ではシャットダウン時にブルースクリーンも出ず1〜2秒くらいでOFFしましたが、郵便番号辞書をアップデートして以後はブルースクリーンが10秒ほど表示されました。

2009/09/07 05:16 M3CSL への返信

M3CSLさま。


ご返信ありがとうございます。M3CSLさまがATOK 2008のSnow Leopard用アップデータ(at21up3.dmg) を当てても大丈夫だったということは、きっと私の環境も問題なんでしょうね。こちらでATOK2008の新規インストールおよびアップデートを2度試したところ、2度ともアクセス権がすべて「読み・書き」に変更になっていましたから。原因がよくわからないので、明日、JustSystemsに電話してみます。その回答をこちらに書き込みますね。


追加情報、誠にありがとうございます。犯人はa21y0906.dmgだったのですね。ソフトウェアのアップデータはSnow Leopardに対応していても、郵便番号辞書のアップデータは対応していないなんて、盲点でした。郵便番号辞書自体は動いているみたいなので、単にアップデータの不具合なんでしょうね。検証してくださり、ありがとうございました。


ところで、ATOK 2009をお持ちの場合、テストでインストールしてくださった2008は当然削除しますよね?! もしもお時間がございましたら、ATOK 2008のディスクからATOKが削除できるか試していただけませんか? 私がSnow Leopardが動いているMacに2008のディスクを挿入し、ATOK 2008を削除しようとアンインストーラーを起動したところ、「このMacにはATOK 2008はありません」という趣旨のメッセージが表示され、うまく削除できませんでした(そこでLibrary/Input Methodや~/Library/Application Support/JustSystems/ATOK,~/Library/Preferences/ATOK21などを手動で削除した次第です)。



いずれにせよ、大変参考になりました。情報、ありがとうございます。

このスレッドはシステム、またはAppleコミュニティチームによってロックされました。 問題解決の参考になる情報であれば、どの投稿にでも投票いただけます。またコミュニティで他の回答を検索することもできます。

シャットダウンが遅くなってしまった

Apple サポートコミュニティへようこそ
Apple ユーザ同士でお使いの製品について助け合うフォーラムです。Apple Account を使ってご参加ください。