iPhoneが謎のいたずら電話を勝手にかける事件〜犯人は音声ダイヤルと特定し一件落着

iPhone5を使い始めてから半年経つのに最近になってポケットに入れていたiPhoneが勝手にランダムな電話番号に電話をかけるという事案が発生した。

気がついたらiPhoneが勝手に電話をダイヤル中になっていて、相手から
「電話かかってきたけど何か用か？」
という返信がかかってくること数件。
これは事件ですよ

Siriは役に立たないのでオフにしている。
なのに音声に反応して電話をかけているようだと段々判明してきた。
iPhoneは半年前から5なのに最近これが起こり始めたということは、iOS7の新機能が怪しいのか…
で、結局いろいろさがしてみたところ、パスコードロックの中にSiriとは別に音声コントロールの項目があってこれが反応していることが分かった。

パスコードロックがかかった状態で普通にポケットに
iPhoneを入れていると勝手に起動して電話をかけ始める
これにはとても困っていたのだがSiriをオフにしても一向に収まらない…

と思ったらパスコードロックの中にも
音声コントロールの設定があることに気がついた
設定の一般の中のパスコードロックに入る

設定変更にはここで設定しているパスコードを求められる

中に入ると「音声ダイヤル」がデフォルトでオンになっている筈だ
これをオフにすると少なくとも音声コントロール画面から勝手に電話をかけたりはしなくなる
音声コントロールで電話をかけるというと「音声ダイアルは無効になっています」と返事する
本当は音声コントロールそのものを無効にしたいのだがこのやり方は分からなかった

そうだSnapShot使ってみよう〜番外編：Time Machineが「容量不足のためバックアップに失敗」という表示を出してバックアップができなくなった〜ナタで割ったような対処法

1TBの内蔵ディスクを抱いているMacBook Proのバックアップを2TBの外付けHDDに取っている。
方法は毎晩つないでTime Machineに自侭にバックアップを取らせているというそれだけ。

それでずっと問題なかったのだが、Lion導入以来ずっと殺していたSnapShotをアクティブにしたことを先日書いた。
そうだSnapShot使ってみよう〜解決編：Time Machineに入ったらCPUフルアップしてファンがブン回る問題を解決〜要するにTime Machineに入らなきゃいいのよ〜BackupLoupe導入

そのタイミングで思い立ってVMWare Fusionに載っているWindowsXP、7などを一気にアップデートをかけた。
なんでそんなタイミングに思い立つかな…と思うがWindowsUpdateが出たタイミングがこのタイミングだから仕方が無い。

それでTime Machine用の2TB外付けハードディスクも残容量が100GBを切るところまで逼迫していたところに、いきなり負荷をかけたために
「Time Machineのバックアップ作成に失敗しました〜ディスクの空き容量を確保してください」
というような意味合いのメッセージが出てバックアップ遅延マークになってしまった。

これが出ても通常は次回のバックアップの時に古いバックアップをどんどん削除して自動的に空き容量を確保してバックアップできるようになるのだが、今回は何度かバックアップをかけても失敗がずうっと続く。
いろいろ重なって、バックアップしなきゃいけないファイルの量が大量になってしまったからだろうと思う。

このまま新たに要バックアップの積み残しが残ると、段々失敗癖がついてしまうという不思議な性質が、このTime Machineにはある。
試しにGUIでTime Machineに入って過去のバックアップを消して２００GB近く空き容量を確保したが、なぜかバックアップに失敗する。

この場合は細心の注意をもって古いバックアップの負荷になってるところを探して削除していかないといけないのだが…めんどくさい。
これまでの経験則でいうと１ヶ月前のバックアップに用が出てくるケースってまずない。
それよりも最新状態のバックアップが無いことの方がはるかに問題なので、いっそ外付けハードディスクをフォーマットしてしまってバックアップを作り直した。

方法もここまで割り切れば単純で
１）ディスクユーティリティでバックアップボリュームを消去
そのあと一応FirstAidでディスク修復
２）システム環境設定のTime Machineに入ってTime Machineバックアップ先を指定し直す
３）バックアップを開始する

これだけ。

時間はかかるがバックアップもすっきり新しくなって80GB程度になっていた外付けハードディスクの空き容量も1.3TBに増えて当分大丈夫そう。

Time Machineが時々失敗するという問題で悩んでいる人が結構多いようだが、容量の大きいディスクに交換して空き容量が不足し始めたらディスクフォーマットで全消去…とざっくりと対処した方がこのソリューションとはうまくつきあえるようだ。

「空き容量不足」のためにバックアップに失敗が出ても通常Time Machineは
次回バックアップの時に古いバックアップを自動的に削除して
またバックアップできるようになる…はず
ところがTime Machineには大量に積み残しファイルが出ると
なぜか失敗癖がついてしまうという変な性質がある
こういう時はいっそ外付けハードディスクをフォーマットしてしまう
一度フォーマットしてしまうとディスクボリュームの名前を同じにしても
Time Machineはそのディスクをバックアップディスクとして認識できなくなるから
一度バックアップ先を削除して再度指定し直すことで正常にバックアップ開始できる

こうして内蔵1TBの内860GBの領域をバックアップし始めた
所用時間は5時間と出たが実際にはもうちょっとかかった

時間はかかったが2TBの外付けの空き容量は1.3TBにまで増えたので当分大丈夫だと思う
毎回どれくらいのバックアップがあるのかはメニューバーからのプルダウンで確認できる

iOS7とMavericksは取得済み〜iPhoneイタ電事件が再発〜SafariのPDFが表示できなくなっている

さて、iOS7とMavericksだ。

iPhone、iPadはすでにアップデート済みで、Mavericksもインストーラはダウンロード済みで様子見中だ。
このタイミングで昨日も書いたとおりVirtual BoxとWindows実機のVAIOを導入したりでMacをじっくりいじっている時間がないのだが、近日中に何とかする。

ところで各所でも話題になっているようだが、iOS7はインストール時に登録情報などが更新されるのに伴って設定値もリセットされてしまう場合があるようだ。

それがどこに出るかは人によるみたいだが、私の場合は以前にこちらで取り上げたiPhoneが勝手にイタ電をするのを防ぐ設定がリセットされていた。
iPhoneが謎のいたずら電話を勝手にかける事件〜犯人は音声ダイヤルと特定し一件落着

他にもあるかもしれない。

Mavericksのインストーラはダウンロード済み
ついに５GB台と一段とデカくなった
タイミングを外したが諸々片付いてからインストールする予定

iPhone、iPadをiOS7.0.3にアップデート

マイナーアップデートながら今回からMavericksとの互換性を
重視した新バージョンに移行したのか起動時に認証などの設定を要求される

iCloudなどの認証も再設定させられる

アップデート後iPhoneが勝手にランダムに住所録の
電話に無言電話をかけるというイタ電事件がまた再発
この対策としてパスコードロックの中の音声ダイヤルの
設定を無効にした筈が勝手に有効に変わっている
パスコードロックの設定がリセットされてしまうということらしい
他にも別の場所の設定が変わってしまったという報告もある
アップデート後はしばらく要注意だ

今回まとめて諸々アップデートした結果いくつか問題が起きている
Safariがクラッシュするという話も聞くがそれは起こらなかった
かわりにPDFが表示できなくなってしまった
AdobeReaderバージョンがドウタラいう表示に注目
AdobeReaderをバージョンアップした時に勝手に
InternetPluginもインストールされてしまったようだ

Safariのアドオンをチェックしたが今回は引っかからなかった
どうやらまたAdobeはアドオンのスタイルを変更したようだ

SpotlightでAdobePDFviewerで検索
早速/Library/Internet Plug-Insの中に該当プラグインを発見
これを削除した

Web上のPDFもまた軽快に表示できるようになった

iTunesライブラリが共有できない〜例によってACLの仕業か〜一気に解除とかやったらシステムぶっ壊れて再インストールするはめに…よいこの皆さんはマネしないでね

Mavericksを導入した時から私的には問題になっていたのだが、こういう手順でiTunesライブラリのファイルを共有すると自分以外のアカウントでは「ファイルが見つかりません」となってしまう問題が起きていた。

１）MacBook ProのiTunesでCDの取り込みをする…あるいはビデオ素材の購入をする
…当然MacBook ProとAppleTVで視聴可能
２）これをiTunesライブラリとライブラリフォルダごっそりMac miniにコピーする
…当然私のアカウントでiTunesを起動するとMac miniとAppleTVで視聴可能
３）iTunesライブラリをMac miniの他のアカウントにもコピー
…Mavericks移行した後にエンコードしたものは「見つかりません」となってMac miniでもAppleTVでも視聴できない…よってそれぞれのアカウントのiPhoneにもコピーできない
こういうことが起きる。

私の場合家族でiTunesの音楽やクリップを共有するため
~/Music
をそれぞれのアカウントに同期コピーし
~/Music/iTunes/iTunes Music/iTunesOpenLibrary
をエイリアスにしてこの実体を共有フォルダに置いている。

そのライブラリフォルダの実体を覗きにいくとクリップやmp3ファイルがフォルダになっていてその中に実体ファイルが入っており、アクセス権は「読み書き不可」になっている。
当然元のMacBook ProではEveryoneも「読み書き可」になっていたはずなのに、そして今までは正常にこれで共有できていたはずなのに新しいものはアクセス権が勝手に書き変わってしまう。

それで例の「カスタムアクセス権が割り当てられています」というメッセージが「情報を見る」タグに出ている。 これは例のACLらしい。
ACLについてはこちらに書いた。
ディスク交換したMacBook Proが全面的不調に〜everyoneのアクセス権が二つになって「カスタム」が出る場合の（ACLの）解除法

ところがどうもMavericksからACLの扱いが変更されたらしく、Mountain Lion以前はBatChmodでACLを解除できたが、Mavericksから解除できなくなったらしい。
ひょっとして新手のDRMか？

結局Mac miniの私のアカウントでライブラリフォルダに何かコピーしたら毎回フォルダ全体の「情報を見る」を呼び出してアクセス権をすべて「読み書き」にして「内包している項目に適用」を実行しないと見えるようにならない。
毎回これをやらないとだめなのでMavericksになってずいぶん面倒になったものだ。

MacBook Proで取り込んだiTunesファイルをMac miniに
コピーして家族全員のアカウントで利用できるようにしたい
コピーするとこのようにファイルはフォルダになってしまい
「カスタムアクセス権が割り当てられています」をどうしても外すことができない
結局自分のアカウントでiTunesのライブラリフォルダ全体を「情報を見る」タグで
アクセス権を「everyone読み／書き」として「内包する項目に適用」しないと解決しない

一応これで複数アカウントにiTunesのファイルを共有使用することはできるのだが、毎回新規のコンテンツを追加するたびにすべての項目を書き換えしないといけないのがいかにも面倒だ。

そこでずぼらをしたい人はこんなことを考える。（つまりそれは私なのだが…）
ルートボリュームの直下の階層のフォルダにはACLは設定されていないようだし、そのアクセス権を「内包する項目に適用」すればACLを解除できるのでは？
さらにルートボリュームも設定されていないようだから、いっそルートボリュームの「情報を見る」タグで起動ボリュームのアクセス権を全部書き換えてしまえば…

ここで「そんな無茶な…」と思ったあなた…
あなたは正しいです。
私も正常ならこんな無茶なこと思いつかないだろうが、ここんとことても忙しいので疲れていて簡単にACLを外したい一心で正常な判断力が鈍っていたのかも…

そしてMac miniの全体のACLを無効にするために起動ボリュームの「情報を見る」タグで
すべて「読み／書き」にして「内包している項目に適用」をクリック…

はい、その結果がこれ…
デスクトップに「機能拡張『なんちゃら.kext』が見つかりません、インストールし直してください」
の警告ポップアップがいくつも出てきてアクセス権の修復をやって再起動すると
画面が真っ白になってSystemUIServer（メニューエクストラ）とドックが起動しない…
Finderも起動しない（キャプチャの状態）…
さらにSUMで修復後は起動すらできなくなってしまった…要するに「システムがぶっ壊れた」状態
馬鹿ですなwww

外部ボリュームからのアクセス権修復も効かないので結局システムのインストールからやり直し
Mavericksのインストール、Time Machineからアカウントの復元へ進む予定←イマココ

なんとMac miniのMavericksはたった一ヶ月でぶっ壊れて再インストールするはめに…
こんなことOS9時代にはしょっちゅうあったけど、OS Xになってから初めてだ…ってぶっ壊した自分が悪いんだけど。

以前どこかのブログで
「アクセス権の『内包する項目への設定に適用』は危険だからやらないように…」
なんて書いてあったが、それは違う。
『内包する項目への設定に適用』が危険なんじゃなくてそれをやる場所が問題だということだ。
『内包する項目への設定に適用』自体はたくさんのファイルのアクセス権を一気に書き換えられる便利な機能だ。
安全な場所でやれば何ら問題はない。
しかしシステムフォルダを含む領域では絶対にやってはいけない。

こんなこと普段なら「あたりまえじゃないか」と思うような話なのだが、やっぱり疲れていたんだろうなぁ。
こうやれば手っ取り早く「ACLをはずせるじゃん！」と思いついたらついつい試したくなって、それをやったらどういう影響があるかを全く考えていなかった。

Terminalの最近のシェルでは
sudo rm -rf /
とか打ったら「この操作はシステムに重大なダメージを与える可能性がある」とか警告が出るようになったのに、CUIですらそうなのにGUIのこのアクセス権の操作は「システムぶっ壊す恐れがあるよ」とか警告が出ないんだな。
誰でもできるシステムのぶっ壊し方。ただしrootのパスワードは必要だが…

そういえばTerminalで初めてsudoを使う時は最近のシェルは
「使用する前にmanをよく嫁」
という味気ない警告が出るようになったが、Macが初期に採用していたtcshでは以下のような文面が出ていた。

 We trust you have received the usual lecture from the local System
 Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

 Password:

訳すと
「あなたはシステム管理者から十分レクチャーを受けているものと信じる
それは突き詰めると以下の三点につきる

１）他人のプライバシーを尊重せよ
２）タイプする前に考えろ
３）偉大なる力には偉大なる責任が伴う

パスワード…」

ということになる。
この３つ目はスパイダーマンのベン叔父さんの言葉だ！と最近気がついた。
そうか、ベン叔父さんは工場勤めだと言っていたがユニクサだったんだ。
２つ目のタイプしてエンターする前に「本当にやってしまって大丈夫なのかもう一度考えろ」というのも味わい深い言葉だ。
今回まさにそういう体験をした訳だから、これも教訓だな
Think before enter password and click OK!
「パスワード入れてOKボタンをクリックする前にもう一度考えろ」

『Mavericks Safariを以前のサクサク軽快Safariに戻す方法』を試してみた〜Safari高速化のためというよりMavericks高速化のためにメリットあり

MavericksになってからSafariがもっさりしていると感じている人がいるかもしれない。
あるいは私の場合はSafariがというよりもMavericksになってOSがもっさりしていると感じていたのだが、この場合も効果があるかもしれない方法。

ネタ元はこちらで、既に各所で話題になっているので試してみた。
Mavericks Safariを以前のサクサク軽快Safariに戻す方法 - Drift Diary XV

これが効果がある条件はSafariで大量のタブを開きっ放しにしている人ということになる。

私の場合「後で読む」機能の代わり、Googleリーダーもなくなってでもやっぱりブックマークには「ちょっとの間保存しておきたい」というURLは入れたくないということで、Webで見つけてきたページをタブで開きっ放しにしている。
その数、常時４０程度で多い時には５０〜６０までいくこともある。

たくさん開いているとSafariが重くなるだろうなということは常日頃感じていたのだが、Mountain Lionまではそれでもまあ問題なく使えていたのであまり気にすることもなかった。

ところがMavericksにしてから、Safariの起動ももっさりしているし、多分Safariの影響でOSも全体的にもっさりしているという印象が強かった。
この後者の方の問題は、この方法で解決する。

方法はキャプチャー参照だが、debugメニューを表示するのにTerminalを使いたくないという人向けにSecretsを使う方法を紹介した。
これならコマンドを使わないでできるがやっていることは同じことだ。

それで結果の方だけども、実際には４５個タブを開いた状態でPer-Tab Web Processを有効、無効を比べてみたがSafariの描画に関してはあまり差がないと思う。
無効にしたからといって劇的に速くなるわけではない。

ただメモリの節約効果は結構絶大で、特に私のように何十個もタブを開きっ放しにしているような人ならメモリを数百MB、プロセス数もタブの数だけ節約できるので、同時に立ち上げたVMWare FusionのWindowsやPhotoshopのような大物ソフトは軽くなる。
むしろこちらの効果の方がメリットが大きいと思う。

システムの動きがもっさりしていたのもかなり解消できた。
何となく思いなと感じていたのはSafari7が原因だったのかもしれない。
そういやログイン中はブラウザは常時立ち上げっぱなしだもんね。

家サーバーのMac miniのVPNなどが重くなった理由はもっと別の問題だろうけど、そういうバックグラウンドプロセスの重さ以外の問題のかなりの部分は、このSafariPer-Tab問題で解決すると思う。

とある日の私のデスクトップ常駐のブラウザ、Safariの姿
この通り常時４０〜６０程度のタブを開きっぱなしにしている
メモリを食わないわけがないしこの状態でVMWare Fusionを起動して
Windows7とか動かしてみたりして「Mavericksは重いじゃねえか(ﾟДﾟ)ｺﾞﾙｧ!!」
とか言っているんだからいい気なもんである

そんな私にも福音のようなTips「Per-Tabウエブプロセスを無効にする」設定法の手順を
まず上記ネタ元サイトではコマンドを使ってdebugメニューを表示する方法が
紹介されているがSecretsを使えばコマンドを打たずにdebugが表示できる
MavericksになってSecretsのメニューのかなりが無効になっているが
Safariの「debugメニュー-インターナルを有効」はMavericksでも活きている
すぐ上隣の「debugメニューを有効」はいじる必要はない

Safariを再起動するとメニューにDebugという開発メニューが見えるはずだ
Safariの設定にも「開発メニュー」というのがあるがそれとは別物
この一番上の「Disable Per-Tab Web Processes」にチェックを入れてまたSafariを再起動する

「シングルウエブプロセスに切り替えてもいいのか？」という確認が出る
もちろん「Switch and Quit」を

設定変更前はこんな感じ
どうやらタブの数だけということではないらしいが
それでもかなりの数の独立したプロセスがメモリを食っていた
一個あたりは20~150MBというところか

Per-Tabプロセスを無効にしたところメモリを取っているプロセスは一個になった
一個で850MBだからビミョーな感じ

何度か切り替えてメモリの空き容量比較テストの結果
こちらはデフォルトのまま

Per-Tabを無効にすると空き容量はこんな感じ

少し条件を変えてテスト
こちらがデフォルト

Per-Tabを無効にするとこんな感じ
総メモり空き容量は逆に悪化しているように見えるが結局ワイアードになっていない…
つまりすぐに使えるメモリの空き容量が増えているわけだから改善はしていることになる
ただSafariの描画速度の向上はあまり期待しない方がいい
私のところでは体感的にあまり差がなかった
それより他のアプリのメモリを圧迫しないというメリットの方が遥かに大きい

さらに大きいのはPer-Tabだとこの通りCPUのリソースもそれぞれのプロセスが
各個に取りにくるからSafariを起動しているとMac全体がもっさりするということが起こっていた
これが解消されるというメリットの方が体感的には大きい
そのためにこそこのTipsはやっておくべきだと思った

「ローカルスナップショットは２〜３GB程度にしかならない」はウソだった〜そしてバックアップ破損で空き容量が100GB失われる〜またシステム終了に失敗癖も再発〜結局Mavericks再インストールへ＜追記あり＞

ここ数日、というより先日ディスクをフォーマットしてMavericksを入れ直した時から内臓ディスクの空き容量の表示がおかしくなっていた。

MenuMetersやディスクユーティリティは空き容量を100GB程度と表示しているのに、Finderは200GB以上空き容量があると表示している。

まだOSがおかしいのかと思ったが、この原因が判明した。
ローカルスナップショットがOS再インストール以来、大量に内部にバックアップを取ってこれが100GBを超えていたのが判明した。

これについては、以前どこかの個人ブログに
「ローカルスナップショットは１〜２GBしか容量を取らないから、ローカルスナップショットを殺すのはディスク容量の節約にはほとんど寄与しない」
ということが書いてあって
「おかしいな、そんなはずないんだが」
とずっと疑問に思っていたのだが、今回その疑問が晴れた。
やっぱりローカルスナップショットも100GBを超えることがあるのだ。

詳しくはこちら参照
そうだSnapShot使ってみよう〜Time Machineのローカルスナップショット機能は使えるようになったか〜それとオンオフアプリSnapShotKill更新しました

結論から言うとローカルスナップショットは数GBしかバックアップを取らないなんてことは、それぐらいしかバックアップ領域を取れないほどディスクに空き容量が無い場合にかぎる話で、空き容量に十分余裕があれば今回のように100GBでもバックアップをローカルに取る。
もっとあればテラバイトクラスのバックアップも取るかもしれない。
だからローカルスナップショットをオンにしていると、内臓ディスクの空き容量は常に100GB前後または10%程度に圧縮されてしまう。

先日のOS再インストール以来ディスクの空き容量表示が変だった
MenuMetersやディスクユーティリティは空き容量は100GB程度しかないと
表示するがFinderは空き容量が200GB以上あると表示している
しかもこの差は日に日に開いていく

その原因が判明した
「このMacについて」の詳細でストレージを見ると100GB以上
ローカルディスクにバックアップを取っていた

バックアップを取っていたのはもちろんローカルスナップショットだった
Time Machineに入ると白く表示されるローカルディスクのバックアップが大量にあった
外付けハードディスクへのバックアップは成功しているがローカルスナップショットは
ディスクに余裕がある時はローカルにも無制限にどんどんバックアップを取るというのが仕様らしい

以前にも書いたがこのローカルスナップショットはディスクの空き容量が少なくなってくると、過去のバックアップを削除して常に空き容量を確保するのでこれ自体は無害なはずだった。

なのでLion導入時に速攻でkillしたローカルスナップショットを、最近気まぐれでまた使ってみようと有効にしていた。
ところが今回このローカルスナップショットが問題を起こした。

Time Machineをオフにする、あるいはSnapShotKillでローカルスナップショットを無効にすれば、このディスク容量を圧迫しているバックアップは自動で消えるはずだった。
前回は確かにそういう動作をした。

ところが今回はそれをやっても空き容量が増えない。
ディスクのクリーンアップのメンテを一通りやって、再起動してApplejackまでかけたのに変化無し。

そこでバックアップを見てみたが、/Volumes/Mobilebackups/Backups.backup.dbというディレクトリが前はあったが、ちゃんと消えている。
しかしこれも以前以下の記事で書いたようにこれはハードリンクの影で、Time Machineのバックアップの実体はここにあるわけではなく不可視領域を表示しても見えないさらにインビジブルなHFSバックアップ領域があってそこの実体が不具合で消えずに残ってしまったようだ。

Time Machineボリュームの中身は手動で削除したりしてはいけない〜正しいディスク容量確保法＜追記あり＞

ここの記事でも書いたがBackups.backup.dbは絶対に手動で削除してはいけない。
Terminalでrmコマンドを使えばひょっとして削除できるかもしれないが、この.dbの領域は合計でも数十MB程度しか容量がないハードリンク（エイリアスのようなものだがもっとファイルシステムよりの仕組み）の固まりでしかない。
これを消してしまうとTime MachineなどのGUIやTerminalなどのCUIでは触れない領域にバックアップの実体があるので削除ができなくなってしまう。

ハードリンクそのものがこんがらがったスパゲッティのようなものなのでそこは直接触ってはいけない。

今回はその.dbを削除してしまったと同じ状態になぜかなってしまったようだ。
これまで外付けハードディスクのTime Machine領域でこういう問題が起きた時の対処法はとてもシンプルだった。

「ディスクを初期化してTime Machineを再設定してバックアップを取り直す」
これしか方法はない。

ところが今回はローカルスナップショットなのでMacBook Proの起動ボリュームの中にバックアップがある。
どこにあるかはJaguarなどの古いOSにボリュームをマウントしてみないと見えないので分からないが、多分起動ボリュームのルートに「.HFSなんとか…」みたいな名前のフォルダとして存在しているはずだ。
今手元にそれができる環境がないので確認できないが、これをボリュームを初期化しないで削除する方法がないかググってみたが、成功例が見つからない。

うまくいっても不具合の原因に遅かれ早かれなるか…

今からローカルでMavericksの上書きインストールを試してみる。
先日来再起動に失敗する癖がまた再発しているので、その検証も兼ねている。
これでバックアップが消えればいいけど、消えなければまた内臓ディスクの初期化をするはめになる。
年末にやっているので１週間もしないうちに２回目だ。
OS9時代はしょっちゅうだったが、OS Xになってこんなにインストールを繰り返すのは初めてのことだ。

教訓としてはMavericksではローカルスナップショットは殺すべしということか。
（ひょっとしてMavericksだけではないかもしれないが）

このバックアップ領域がどんどん膨らんでいくのでこれを削除するために
SnapShotKillを使ってローカルスナップショットを無効にした
前回はこれでバックアップはすぐに消えたのだが今回は
消えたのは消えたが『その他』の領域が100GB増えた
バックアップが削除されずにそちらに移行してしまったらしい

元に戻すと/Volumes/Mobilebackups/Backups.backup.dbに
新しいバックアップはできるが古いバックアップは見えなくなってしまった
これは誤ってこのBackups.backup.dbを手動削除してしまった時と同じ症状だ
要するにバックアップが破損して操作できなくなってしまったという状態だ

キャッシュやメモリクリア、仮想メモリのクリア、再起動してApplejackと
考えられることは一通りやってみたがやはり『その他』は100GB増えたまま
Finderの空き容量表示も一致するようになったが残り30GBと悪い方に統一されただけだ

不可視領域を表示してこのバックアップの実体が見えないか探してみたが
やはりleopard以降のOSではこれは見えない
これを見るには古いOSにターゲットモードでマウントしないといけない
起動ボリュームを初期化して再インストールしかないか…また半日つぶれるなぁ…

ちょうど数日起動しっぱなしで使い続けると再起動に失敗する問題がMacBook Proで再発していた
そこでまずMavericksを内臓ディスクから上書きインストールしてみることにした

この通り強制終了をするとシングルユーザモードに入ってfsck -fyコマンドを実行した時に
The Volume was modifiedという警告が出る
これが出たら出なくなるまでコマンドを繰り返すのが鉄則だが
どのみち起動ボリュームにストレスがかかっていることは間違いない
この問題も解決したいので上書きインストールを試してみる

インストール前の在りし日のMacBook Pro
これから何されるかも知らないで…
上書きインストールで不良バックアップが消えてくれればいいんだけど…まずダメだろうなぁ
おそらくディスク初期化は避けられないと思うが一応試してみる

＜追記＞
Mavericks上書きインストール完了。
結果はやっぱり惨敗。
ディスク空き容量は6GBちょい増えただけでOS Xインストーラが完了して削除された分だけ容量が増えただけの結果となった。

つまり孤児になったバックアップ100GBはまだ起動ボリュームの中にいるということだ。
帰ったら早速ディスク初期化かな…空しいなぁ

Mavericks上書きインストール完了
ディスク空き容量は6〜7GB増えたがほとんどインストール完了して
削除されたOS Xインストール.appの大きさなので全く改善していない
このまま再起動失敗が改善したかテストしたい気もするがどんどん計画が
遅延しているのでもう見切りを付けて初期化してしまおうか…

「ローカルスナップショットは２〜３GB以上増えない」はウソ〜は間違いかもしれない〜バックアップ破損で空き容量が100GB失われたのはメタデータ原因の誤表示〜でもMavericksのバグは間違いなさそうだが…

先日ローカルスナップショットで100GBを超えるバックアップ領域ができて、スナップショットを無効にしたところこれがそのまま「その他」領域に組み込まれて、破損したのではないかと先日書いた。
参照。
「ローカルスナップショットは２〜３GB程度にしかならない」はウソだった〜そしてバックアップ破損で空き容量が100GB失われる〜またシステム終了に失敗癖も再発〜結局Mavericks再インストールへ＜追記あり＞

その後このMacBook ProをTキーを押したままディスクターゲットモードで起動。
これを老兵iBook DualUSBにFireWireで繋いでマウントしてみた。

Time Machineのバックアップは以前にも書いたが、あたかもBackups.backupdbというフォルダの中に日付順に並んで保存されているように見えているが、これはハードリンクで構成されたバックアップの影でしかない。
Time Machineのバックアップの実体はルート直下の
.HFS+ Private DIrectory Data
というフォルダの中にある。
しかも元の起動ボリュームとは全く似ても似つかない姿で保存されている。

これはLeopard導入の時に確認していたのだが、今も変わっていなかった。
そしてローカルスナップショットの実体ファイルはやはり起動ボリューム直下の同じ名前のフォルダの中にあった。
これはOS Xの不可視属性とはまた違う仕組みで不可視に設定されておりMainMenuなどのユーティリティを使って、不可視ファイルを見えるように設定してもこのバックアップの実体は見えない。
Time Machineが採用される以前の古いMacにマウントしてみるとこれが見えるわけだ。
（ちなみにiBook DualUSBのOSは、TigerたんOS10.4.11だ）

ただし今回はその中身を見たところ、空っぽだった。
やはりローカルスナップショットを無効にした時点でその中身はきれいに削除されるらしい。

ここまでのおさらい
ディスクユーティリティとFinderの空き容量表示があまりにも違うので
Appleメニューの「このMacについて」の詳細でストレージの中の
構成を確認したところバックアップが105GBとなった
ローカルスナップショットを有効にしてバックアップを取っていなかったために
内臓ディスクにバックアップが大量に溜まったのだと判断した

そこでSnapShotKillを使ってローカルスナップショットを無効にしたところ内臓ディスクの
空き容量が105GB増えるのではなく「その他」の領域が100GBほど増えただけになった
Time Machineを無効化してまた有効化したりいろいろ試したが
この100GBは空き容量にならずにその他領域で定着してしまった
どうやらシステムでいじれないゴミが100GBできてしまったと判断した

そこでMacBook ProをTキーを押しながら再起動
久しぶりに起動したiBook DualUSBご老体にFirewireで接続し
いわゆるディスクターゲットモードで外付けハードディスクのようにマウントしてみた
Time Machineのバックアップの実体はBackups.backupdbというGUIで見えているフォルダではなく
こういう旧OSでマウントしないと見えない特殊な不可視フォルダ
.HFS+ Private Directory Dataというフォルダの中にある
そのフォルダを開くとこのようにTime Machineのデータベースとして
元の起動ボリュームとは似ても似つかない姿で保存されているはずだ

ところが今回MacBook Proをマウントしてみたところ
その.HFS+ Private Directory Dataの中身は空っぽだった
他の場所も探してみたがゴミになったDBの残骸は見つからなかった

さらに旧OSでも見えないもう一段不可視な領域にでもなっているのかと思い
サイズを検証してみたがこのフォルダやはりサイズ0KBとなっていてどう見ても中身空っぽ

念のためにこの.HFS+ Private Directory Dataをゴミ箱に入れて削除してみた
Tigerタンならこんな無茶もできる…

が、結局MacBook Proを正常起動してみると何も変わっていなかった
100GBはやはりその他の領域に組み込まれただけ

TigerタンでSpotlightのデータベースも削除していたのだが確認のため
また「このMacについて」の中身を見たところなんと全領域が「その他」になっている
数時間待ってメタデータが作成されたらまた100GBが
「その他」に組込まれた２番目のキャプチャの状態に戻った
つまりこのストレージの領域やFinderの空き容量表示はメタデータをもとにしているということだ

ここでそろそろ現実的な思考をしないといけない
ユーザフォルダの中のVMWare Fuion、Virtual Boxの
仮想マシンファイルの合計が150GBを超えていることに気がついた
つまり「その他」領域が170GBちょっとしかないという最初の
ストレージの表示の方が実はおかしかったということだ
Finderもそれに連れてバギーな表示をしていたということだ
バックアップが100GB以上もあったというのは間違いだったらしい

ということで今回もゴミがどこかに隠れていないかディスク初期化、OSクリアインストール、Time Machineからユーザ領域復元…を実施したが空き領域は増えなかった。

そしてディスクの中を徹底的に洗ったところ、VMWare Fuion、Virtual Boxなどの仮想マシンファイルの合計が150GBを超えていることに気がついた。
それに諸々のユーザファイル、システムファイルなどを合計すると170GBというのはあり得ない数字だ。
GarageBandなどのサウンドファイルも入っているしね。

ということでバックアップが100GB以上あるという表示の方が間違いだったことに気がついた。
そしてこれらの領域表示はSpotlightのメタデータを利用していること、Finderの空き容量計算もメタデータを利用しているため、メタデータが間違って「バックアップ」と判断してしまうとそれも空き容量として表示してしまうことが分かった。

だから空き領域が100GBしか無いのに200GB以上空き容量があるという誤表示をFinderがしてみたり。
これの解消法はSpotlightのメタデータ削除しか無い。
システム再インストールでもいいけど。

そしてさらにやっぱりローカルスナップショットは殺しておくべきだなとも思った。

もう一度ご案内。
弊サイトで配付しているローカルスナップショットをkillするアプリ。

SnapShotKill

こちらがLion以前のバージョン向け。

SnapShotKill

そしてこちらがMountain Lion、Mavericks向けのバージョン。
間違えないようにダウンロードして使ってほしい。

アプリケーションフォルダなどルートボリュームのいくつかのフォルダがTime Machineでバックアップできなくなった

またまたTime Machineのトラブル。

というより正確にはMavericksのトラブルか？

古くなって陳腐化したMacを近代化改修するシリーズ第２弾、Mac miniをハイブリッドドライブ化する手術を先日断行した。
その経過と結果については近日中にまとめてここにアップする予定だが、その過程で内臓ディスクを取り出して、外付けハードディスク化し、従来のでかいハードディスクは外して新規でバックアップを取り直し始めた。
問題はこの時に起きた。

Mac miniをハイブリッドドライブ化、取り出した1TBを
外付けハードディスク化し早速Time Machineでバックアップを取る
ウキウキしてベンチマークを取りはじめたいところだがTime Machineの
バックアップでユーザフォルダとその他の領域しか
バックアップできないていないことに気づく

ディスクを交換する前は普通にシステムフォルダやアプリケーションフォルダもバックアップできていた
Time Machineの環境設定を確認しても特にバックアップの除外領域ファフ得ているわけでもない

もっと詳細な設定項目は無いものかと途方に暮れたがMacにはそういう設定項目は存在しない
/Library/Preferences/にあるcom.apple.TimeMachine.plistという設定ファイルを開いてみた
すると上記設定項目には無い「ExcludeByPath」という項目がいくつもできている
意味はまさに「除外項目」でここに/Systemや/Library、/Applicationsだけでなく
/bin、/var、/etcなどのUNIX側のシステムファイルもほとんど除外されていた
このままではアプリも消えるしシステムやユーザの設定ファイルも
大部分バックアップされていないので意味をなさない

これらの項目を削除するエディット可能だが面倒なので件の
com.apple.TimeMachine.plistというライブラリ設定ファイルを丸ごと削除した
当然Time Machineの設定は初期化される
削除して再起動するとまっさらの設定のcom.apple.TimeMachine.plistができ上がっている

そうしてバックアップを100GBほど作り始めて数時間
Time Machineのバックアップの中にはアプリケーションフォルダや
ライブラリフォルダ、システムフォルダが見える
不可視化されているがちゃんとUNIX領域もバックアップされているはずだ

ちなみに動作が正常なMacBook Proのplistファイルを見ると
ここは大部分はキャッシュファイルを除外する設定のようだ
時間がある時にこれらの設定を復元しないと今度はキャッシュが
Time Machineの容量を食ってしまいそうだ

これが起きた原因だが、設定ファイルが勝手に書き変わるMavericksの特有の癖というかバグというかその生徒しか思えない。
ロックファイルという拡張子のゴミができたりあちこち設定が勝手に変わってしまうなど何かとMacもセキュリティ強化の煽りで不便になってきた。

この問題の解決策は上記の通りライブラリフォルダ（ユーザの中のライブラリフォルダではない）にあるTime Machineの設定ファイルを削除して初期化するという単純なものだった。

今回はバックアップが正常に取れない理由について結構悩んだので、このバグには何遍も煮え湯を飲まされている。 他にもいくつか問題はあるのだが、後日まとめよう。

ともかくTime Machineの挙動がおかしいと思ったら
/Library/Preferences/com.apple.TimeMachine.plist
を削除してみることだ。
設定だけでなく場合によってはバックアップしたファイルも失うかもしれないがこれが最も簡単で有効な方法だ。

Mavericksアップデート以降スリープから復帰できないという問題が時々起こっている〜そのとりあえずの暫定的な回避法

Mavericksに上げてから時々起こっていた問題なのだが、MacBook Pro、Mac miniともにスリープから抜け出せなくなることがある。

毎回ではないがMacBook Pro、Mac miniともにFusionDrive化、ハイブリッドドライブ化してMavericksをインストールし直してからちょくちょく起きるようになった。
おそらくドライブは関係ないのだろうが。

これは調べると割と該当記事が沢山引っかかった。

新型MacBook Proの一部にフリーズの不具合 Mavericksのバグか ガジェット速報

MacBook Air (13inch, Mid 2013) をMavericksに更新後、スリープからの復帰に失敗する Apple サポートコミュニティ

しかし
「今回のバグは新型MacBook Pro 13インチモデルのほか、ごく一部の15インチモデルでも問題が生じていると伝えられています。」
とあるが、まいどまいど強調するけど私のMacBook ProもMac miniも2009年モデルなのでこのドライバーのバグが原因なのかは不明。

症状はスリープから復帰すると黒画面のまま。
よく見ると完全な画面が落ちた状態ではなく、バックライトはしっかり点灯しているが画面が黒になっている。
上記ディスカッションボードのこの症状に近い。
「スリープから復帰した際、画面がブラックアウトし全く操作不能に陥ります。」

完全に操作を受け付けないわけではなくキーを叩くたびに「無効キー」の警告音が鳴るので（私のMacBook Proはそういう設定をしているので）黒画面の向こうで何らかの操作画面は立ち上がっているらしい。
しかしloginwindow.appアプリがおそらくちゃんと立ち上がっていないので、ロックを解除できない感じ。

ディスカッションボードにあったようにMacBook Proの場合はふたを閉じて一度強制的にスリープさせてもう一度開くとロック解除画面が出てくるという方法で、一度は解除できている。
だが、それができないこともある。

何ともならない時は結局強制再起動しか無いので、これはできるだけ避けたいところだ。

結局この問題はloginwindow.app、logindというシステムコアサービスに
入っているアプリが正しく起動しないのが原因で新しいMacBook Proで
発生しているグラボドライバーのバグとはまた違う問題かもしれない
これが起こる条件はスリープ／スクリーンセーバ解除時にパスワードを
要求するセキュリティの設定にチェックが入っているということらしい

そこでスクリーンロックとして代わりに先日ここで紹介したhandyLockを使うことにした
iPhoneが近くにある時だけ自動的にスクリーンロックが
解除されるこのアプリでモバイルのセキュリティは多少ましかも
どのみちシステムのスクリーンロックそのものも
そんなに堅牢なセキュリティではないので代用品としては十分といえる

そしてスリープ解除時のパスワード要求設定は解除した
これでスリープからスムーズに復帰できるか様子を
見ているところだが今のところ良好のようだ

スリープからはパスワード無しで復帰するがMacから離れている時はロックがかかる
これでも目的は果たせると判断した
問題はこれでスリープから復帰できなくなる問題を回避できるかだ

システム環境設定のセキュリティの設定で今まで「スリープ解除／スクリーンセーバ解除にパスワードを要求」にチェックを入れていた。
持ち去られた時、紛失した時盗まれた相手が十分情弱なら多少個人情報を守る役に立つかもしれないという意味でこの設定をしているのだが、これを解除するとスリープから復帰できなくなる問題は解決するというディスカッションボードの情報があったので今検証中だ。

ただスクリーンロックを何もかけないのは、いくら見かけのセキュリティ対策といっても心もとないのでキャプチャーの通り先日ここで紹介したhandyLockを代用品としてかけている。

今のところこれでスリープ解除の不具合は起きていないが、様子を見ているところだ。
Mac miniに関してはこれが起こった時に画面共有で入って遠隔からスリープを解除することで復帰できるようだ。

Terminalコマンドの履歴が消えてしまった〜やっぱり無いと不便なので復元してみた

Terminalを結構便利に使っている。

私はUNIXネイティブな人ではないので、MacはもともとGUI中心に使っていた。
だからコマンドを使うのは億劫…という人の気持ちも分かる。
だがTerminalは食わず嫌いしないで使ってごらんよと元同類のユーザにお勧めしたい。
使い慣れると本当に便利。

例えばPreferenceフォルダの中のlockfileという拡張子のついた不正な設定ファイルを削除したいという時に、Finderでちまちま削除するより*.lockfileのファイルを削除せよというコマンドを一発打つだけで、何百あるゴミファイルを一瞬で探し出して削除してくれる。

そしてMac OS Xで採用されている現行のbashは過去のコマンド履歴を全て覚えてくれるので、これが強烈に便利。
メンテナンスなどに使うコマンドは全部カーソル上キーで履歴をたどるだけで見つけられる。
あとはエンターキーを叩くだけ。

この機能は本当に重宝していて、あまりにも便利すぎていつまでたってもコマンドをソラで覚えられない。
よその環境で
「〜するコマンド打って」
と頼まれても
「え〜っとsudoなんとかだよな、なんだったっけ？」
といちいちググらないと何もできない、UNIX的にははなはだ頼りない人になってしまった。

ところがここで一大事が出来する。

コマンドを使ってシステムを強制終了するテストを実行していたら、再起動後このTerminalの履歴がきれいに消えてしまった。
Macは時々これがあるからなぁ…

無くても良いかとしばらく使ってみたが、やっぱり無いと不便！
（コマンドくらいソラで打てるように覚えろよ…というツッコミは無しの方向でお願いします）

コマンドの履歴はここにあった
~/.bash_history
ホームフォルダ直下の不可視ファイルで、bashユーザは.bash_historyという名称のファイル。
事情があってtcshなど他のシェルを使っている人にはその名称になっているはずだ。

これをTime Machineのバックアップから、上書きしてTerminalを起動し直すと、履歴が復活した。

ちょっとしたTipsだけど、無くなってみると自分がかなりこの履歴に依存していたことに気がついてちょっと焦ったのでメモしとく。

とある休日の朝、強制終了のテストを終えてTerminalを起動する
カーソル上キーを叩いても過去のコマンド履歴が出てこない
どうやら強制終了、自動復帰の過程で履歴ファイルが壊れてしまったらしい
この機能がないとやっぱり不便なので復元することにした

この履歴ファイルはホームフォルダ直下に不可視ファイルとして保存されていた
大きさは32バイトとほとんど白紙になってしまっているのが分かる

Time Machineのバックアップを見ると昨日までこのファイルは16KBあった
これをMacのファイルに上書きする
Terminalコマンドで華麗にやっても良いが私はGUIで泥臭く上書き

こうしてカーソルキー一発で過去の履歴が呼び出せるようになってめでたしめでたし…
逆に最近の履歴がうざいので一度リフレッシュしたい
という時はこの不可視ファイルを削除すれば良い
Emacsなどのテキストエディタで編集するというのもあり
ちょっとしたことだけど覚えておくと便利かも

iCloudを経由してWindowsのInternet ExplorerやFirefoxのブックマークをMacのSafariに移す〜逆も可能

WindowsからMacにスイッチする時にWindowsのInternet ExplorerやFirefoxのブックマークをMacに移す方法を以前にこのサイトで紹介した。
WindowsからMacにスイッチ（乗り換え）する時の疑問2
〜メールメッセージやブラウザのブックマークを移せるの？

でも今ならもっと簡単な方法でブックマークなら共有することができる。

AppleのiCloudサービスを使えば、iPhoneとMacだけでなくMac同士、MacとWindowsでもいろいろ共有できることは以前にも紹介した。

ブックマークもWindowsのSafariだけでなくInternet ExplorerやFirefoxとも直接同期できる。

方法はAppleのサイトからWindows版のiCloudをインストール、その上で必要なアドオンをブラウザにインストールする。
ここではFirefoxとSafariの同期法をメモしとく。

WindowsのコンパネにiCloudをインストールして起動するとブックマークというメニューがある
これにチェックを入れる

オプションをクリックするとどのブラウザのブックマークを共有するか聞いてくる
ここではFirefoxを選択するがInternet ExplorerやGoogle Chromeも同期可能

Firefoxを起動するとiCloudアドオンのインストールを求められる
iCloudブックマークをインストールする

おなじみのアドオンインストール画面で承認

Macの方のiCloudの設定が完了していれば
もうブックマークに Safariのブックマークが見えるはずだ
両方のブックマークをマージするか聞いてくるのでマージを
選択すればFirefoxのブックマークもiCloudにアップされる

Macの方はシステム環境設定のiCloudを開いてSafariにチェックを入れる
これでMacのSafariとWindowsのFirefoxのブックマーク同期は完成する
相互に更新すれば相手にもマージされるのでいちいち
ブックマークを相手に移すという作業が必要なくなる

ログオン時、Wi-Fi接続時『Keychain "System" cannot be found to store』というメッセージが出てパスワードを要求されログオンに失敗する〜このケースの対処法

海外のサイトでは結構既に話題に挙がっている事象だが、OSのアップデートなどでキーチェーンがダメージを受けてしまうことがある。
この場合、Wi-Fiの接続の度に
『Keychain "System" cannot be found to store "アクセス名"
キーチェーンに保存されたパスワードをリセットせよ』
というメッセージが出てパスワードを要求される。
しかし、リセットには失敗する。
詳細はこちら参照。
Keychain Error- Keychain "System" cannot be found to store "B7F3D" (Wireless network) - apple answer

私の場合、今回OS10.9.3のアップデートに失敗したため、OSを一旦10.9.2にTime Machineで戻して、Appleのサイトから10.9.3Comboアップデートをダウンロードしてきて手動でアップデートを実施した場面で再現した。

アップデート後の状況は概ね良好だったのだが、アップデート後ログイン時とWi-Fi接続時にいちいち
「認証に失敗した、キーチェーンのパスワードをリセットしろ」
という表示が出るようになってしまった。
そしてリセットにも失敗する。
結局ログインにもWi-Fi接続にも成功するので気にしなければ良いのだが、スリープから復帰する度に
「パスワードをリセットしろ」
とかの警告が出るのは鬱陶しい。

Mavericksを10.9.3に手動アップデートした結果、ソフトウエアアップデートで
アップした時に起こっていた問題が解消されたが今度はこういう問題が起きた
ログオン時とWi-Fi接続時にキーチェーンが正しいパスワードを保存できない
という意味の『Keychain "System" cannot be found to store』というメッセージが出る

問題を解消するために「リセットデフォルト」をクリックしてパスワードリセットフォームが出るが
このパスワードフォームにはなぜか入力ができないので結局キャンセルするしかない
そして接続時またパスワードを保存できない、リセットせよという表示が毎回出る

Wi-Fi接続時にワイヤレス診断が自動的に立ち上がってipconfigなどの設定を確認するが問題なしと出る
結局接続には成功しているので気にしなければ良いのだが毎回この表示が出るのはさすがに鬱陶しい

キーチェーンアクセス

この問題に対処するために、このアプリを使う。
キーチェーンで管理しているパスワードなどの状況を確認できるキーチェーンアクセスはユーティリティフォルダの中にある。

これを起動してメニューからKeyChain Fast Aidを実行することで問題点の発見と修復ができる。
これで私の場合解決できた。

ユーティリティフォルダにあるキーチェーンアクセスを起動する
そのアプリケーションメニューの中にKeyChain Fast Aidというメニューがあるのでこれを開く

まずはこれで検証をする方法はルートパスワードを入力して「開始」ボタンをクリック
すると~/Library/Preferences/com.apple.security.plistという設定ファイルが
アクセス権問題を起こしているという表示が出るがこのアクセス権は
ディスクユーティリティなどのアクセス権修復では修復できない

KeyChain Fast Aidの「修復」の方の
ラジオボタンを入れてもう一度開始ボタンをクリック
これでシステム最起動後に修復は反映される
私の場合これでドンピシャこの問題は解決した

App Napを解除してスリープ解除失敗が改善するかを見ている〜どのみちレンダリングするならこの機能は殺しておいた方が良いかも

ここのところシステム終了失敗、スリープ解除失敗の問題に対応するのにずっと手を取られていたことはここに書いた。
その過程でBBSにも書き込みをいただいたが、Mavericksでスリープ解除失敗が多発するということはMavericksの新機能の何かが問題を起こしているんじゃないかという気がしていた。

そんな折り、今月の初めに海外のMac系のサイトに一部のアプリの動作に問題を起こしているApp Napを個々のプロセスで解除するのではなくシステム全体で解除する方法が紹介された。
詳細はこちら。
10.9- Disable App Nap System Wide - Mac OS X Hints

App Napを解除するコマンドは以下の通り。

defaults write NSGlobalDomain NSAppSleepDisabled -bool YES

これをTerminalにコピペしてEnter。
以降起動する全てのプロセスはApp Napが適用されない。
システムごと再起動すれば全てのバックグラウンドプロセスもApp Napが適用されなくなる〜つまりApp Napを殺すことができる。

App Napが生きていることで映像加工ソフトなどのレンダリングに失敗するなどの影響があることが指摘されている。
問題は、影響は本当に画像加工ソフトだけなのかということだ。
アクティビティモニターをチェックすると、そうしたユーザアプリだけではなくシステムプロセスもApp Napが適用されていることが分かる。
loginwindowというログイン画面を表示するアプリやlogindというそれを制御するシステムのdaemonも適用を受ける。
例えばスクリーンセーバーが起動していれば当然そこから復帰する時のパスワード画面はバックグラウンドプロセスになるわけだ。
これはよろしくない仕様なのではないかという気がする。

そこで今回のシステム再インストールを機会に、このサイトで紹介されているTipsを試している。
今のところ良好なのである程度結果が出たら、これまでやった対策をだんだん解除しようと思っている。
省エネルギー設定のディスクをスリープさせない設定を解除して、スリープ解除時にパスワードを要求する設定に順次戻そうと思っている。
それらが完了してもスリープ解除失敗が起きない場合は、App Napの疑いが濃厚になると思っている。
まだ途中経過だが一応の記録として書き留めておく。

App Napを解除するコマンドはdefaults write NSGlobalDomain NSAppSleepDisabled -bool YES
これをTerminalで実行する
元に戻す時はdefaults write NSGlobalDomain NSAppSleepDisabled -bool NO

App Napはアプリごとに「情報を見る」で無効化できる
ここのチェックを入れれば良いのだが全てのプロセスでこれをやるのは現実的ではない
なので上記コマンドで全域で一気に無効化する

アクティビティモニタのエネルギーのページを見ると
それぞれのプロセスのApp Napが無効になっているかどうかを確認できる

表示メニューから「全てのプロセス」を表示させるとFinal Cut ProやHandBrakeのような
ユーザプロセスだけでなくシステムUIのプロセスもApp Napの支配下にあることが分かる
例えばスリープ解除の時にパスワードを要求する設定にしているとloginwindowというアプリが起動する
これを呼び出しているのがlogindだがこれらもApp Napの影響を受けていたことが分かる
スリープ解除失敗の問題と関係があるかどうかは不明だが
今後テストしてこの因果関係を確認しようと思っている