Apple の脅威の通知と金銭目当てのスパイウェアへの対策について

しばらく返答が寄せられていないようです。 再度ディスカッションを開始するには、新たに質問してください。

ハイバネーションモードになった原因について

iMac (21.5-inch, Late 2012), OS X Mountain Lion (10.8.5)使用


基本的に長期留守にする時以外はスリープにしているのですが

1ヶ月半程前に、復帰しようとした所時間がかかり

灰色がかった画面が表示される現象が起きました。


調べた所、ハイバネーションスリープ(ディープスリープ?)からの復帰画面だったようです。


2年以上使って来て初めての現象で、

しかもこのモードは通常はノートPC等の電力消費を抑えるためで

コンセントから電力供給しているデスクトップでは普通は出来ないもののようで

私もまったく心当たりがありません。


そして今日2度目のハイバネーションからの復帰が起こりました。


復帰してしまえば、別に普通に作業出来るのですが、

通常起こらない筈の事が起こってしまうのは不安で仕方ありません。


何か問題がある可能性があるのか、

無ければ原因として何が考えられるか

また、どういう対処をした方が良いのか。

何でも良いので心当たりがありましたらば、ご助言をお願い致します。


ちなみにここ暫くはappストアでのアップデートと、ブラウザ関連の自動アップデート、

Trusteer(銀行サイトのページの保護用)プリンタのドライバ関連以外は余計なアプリも入れていません。

iMac (21.5-inch, Late 2012), OS X Mountain Lion (10.8.5)

投稿日 2015/08/11 10:28

返信
返信: 48

2015/08/17 23:52 mikemi への返信

少し補足しておきます。pmset で設定を変更して設定ファイルに書き込むためには、sudo をつける必要があります。先の例で云えば、


sudo pmset -a autopoweroff 0




sudo pmset -a autopoweroffdelay 43200



です。管理者パスワードを訊いてくるので、入力します。パスワード入力の際は、カーソルは全く動きませんのでご注意を。



補足の補足です。

デスクトップの場合、UPS を使っているのでなければ、autopoweroff は省エネルギーのためだけでなく、安全のためにも無効にしない方がよいと思います。長時間スリープさせていて、しかもセーフスリープ状態になっていないときに停電すれば、システムがダウンするからです。



(補足の補足を追加しました)

2015/08/18 12:27 chandana への返信

補足ありがとうございます。

ご助言に従い、設定を切るのは止める事にしました。

あと色々なサイトを見ている限り、

autopoweroff 1

autopoweroffdelay 14400



の設定は通常の設定なようなので、下手にいじらない事にしました。

(時間を変えれば対症療法にはなるかもしれませんが、症状が突然起きるようになってしまった説明はつかないので)



スリープから復帰時問題について色々な記事を見ていて

時間がかかる→黒い画面がかなり長い(カーソルや虹色くるくるだけ表示?)→復帰

キー操作が効かずパワーボタンを押さないと復帰しない→ディープスリープだった?というような話が多かったのですが



私の場合は

キーボードを叩く→黒い画面が少し長め→ぼんやり灰色がかったデスクトップで下にプログレスバーの画面→復帰

という感じで時間は少しかかる程度です。復帰が比較的早いのでディープスリープとは違う…?



以前、スリープからまったく復帰せずパワーボタンを使った事があり(単発症状)

その時もプログレスバーを見た覚えがありますが、灰色がかった画面では無かった気がします。

セーフとディープでは復帰画面が違うのか、それとはまた別ものなのか…



という事で、今更基本的な疑問なのですが、

セーフスリープとディープスリープの復帰時の症状や画面にはどんな差があるのでしょうか?

Appleのページ等同一視している説明もあるので、色々な情報も判断しにくく混乱しています。



私の症状は結局何スリープに当てはまるのか

どこが正常で、どこからが異常なのか…まだちゃんと理解出来ていないと気がつきました(苦笑)



設定を見る限り4時間でセーフスリープ(@ディープスリープ?)になるのは仕様?

私のPCは少なくとも相談時までは必ずしも機能していなかった様子だった?→それならむしろ今は正常?

色々な症状を見る限り、ディープというより、セーフスリープ?そもそもhibernatemode 0でもなるもの?



サポートの方の反応からして私の環境でハイバネーションの画面が出るのは普通では無いらしい。

→hibernatemode 0の設定には合う

→セーフスリープ自体は仕様という記事があるがそれとは違う?

→結局設定との整合性が取れていないのが問題?OSの再インストールで解決するようなものなのか?



頭の中がこんな感じで、ハードの問題で通常起こりえないハイバネーションモードになり画面が出るのか

ソフト的な整合性が何故かとれてなくて問題が出ているか、まだ判断ついていませんが

みなさまのお陰で手探りしつつ前に進めている感じです。色々なご助言本当にありがとうございます。



ちなみに現時点での電源ログは以下です。

Active Profiles:

AC Power -1*

Currently in use:

standby 0

powerbutton 1

womp 1

halfdim 1

hibernatefile /var/vm/sleepimage

autorestart 0

networkoversleep 0

disksleep 0

sleep 10

autopoweroffdelay 14400

hibernatemode 0

autopoweroff 1

ttyskeepawake 1

displaysleep 10

standbydelay 4200



周辺環境は以下です。

無線でキーボードとマウスとプリンタ(wifi無線の接続不良で問題が顕著になる前日にドライバ等を更新)

有線でワコムのペンタブレット、外付けHDDとiPhonは必要な時だけ接続。(自動バックアップは切)



>「ネットワークアクセスによるスリープ解除」をON にしていると通常は2 時間弱でスリープ解除されます

ここ数回のログを見る限り、スリープ2時間で何かが動いている感じはありません。

ドライバ更新がきっかけになりこの動作が阻害されて、現状に至るとかはあり得るんでしょうか。

(ディープスリープがhibernatemodeが0でも動作する事があるものならば)

2015/08/19 00:16 mikemi への返信

mikemi さんによる書き込み:


>「ネットワークアクセスによるスリープ解除」をON にしていると通常は2 時間弱でスリープ解除されます

ここ数回のログを見る限り、スリープ2時間で何かが動いている感じはありません。

「ネットワーク解除によるスリープ解除」がオンになっていると一般的にはコンソールで「wake re」でフィルタリングすると下記のような感じになります。

2015/08/18 0:12:10.000 kernel[0]: Wake reason: RTC (Alarm)

2015/08/18 2:01:04.000 kernel[0]: Wake reason: RTC (Alarm)

2015/08/18 3:49:58.000 kernel[0]: Wake reason: RTC (Alarm)

2015/08/18 5:38:52.000 kernel[0]: Wake reason: RTC (Alarm)

2015/08/18 7:27:45.000 kernel[0]: Wake reason: EHC2


最後の2015/08/18 7:27:45.000 kernel[0]: Wake reason: EHC2 が私がスリープ解除したものです。

ドライバ更新がきっかけになりこの動作が阻害されて、現状に至るとかはあり得るんでしょうか。

何かをきっかけに設定が反映されなくなるとか変更された状態になることはあり得ます。

2015/08/19 10:02 ni_ki への返信

いつもありがとうございます。

最初の相談時にWake reのログをとれていれば良かったのですが

ログが流れてしまって、以前はネットワークアクセスによる〜の設定が動いていたのか判らなくなってしまいました。


一応ドライバ更新後にディスクのアクセス権の修復はかけているのですが、それでも解決しないとなると

OSの再インストールしか無いのでしょうか…

でもネットワークアクセスによる〜をoffにすれば、ハイバネーションになるという程単純なら

サポートの人の反応はなんだろう?とも思いますが、単純に事例があまり無いだけかもしれませんね。


>ネットワークアクセスによる〜がonになっているのに、動いてないらしい?→それが4時間後のディープスリープを呼んでいる?

>hibernatemodeの設定が0なのにディープスリープになる

2つめが、4時間でディープスリープになるのがこの設定とは別に動くとかなら、ハード的な問題は排除出来るかも?


ここ2回については4時間でディープスリープになっているらしい→復帰時ハイバネーションから復帰の画面になる

という以外に、目に見える形で害は出ていないので、


ディープスリープ事態がPCに害があるものでなければ、検証を兼ねて

これから数日スリープ多めで(最近長時間スリープさせないようにしていたので)やってみようと思います。

昨日、システム指定のアップデートをかけてアクセス権も修復をしたので、

それでまたネットワークアクセスによる〜の動きが正常になっていれば…と一縷の望みをかけています…


また何かお気づきの事がありましたらよろしくお願い致します。

2015/08/19 23:44 ni_ki への返信

本日、4時間未満と10時間程のスリープを試しましたが、4時間超えの方で復帰時ハイバネートの画面が出ました。

(4時間でWake reason: EC.SleepTimer (SleepTimerのログ)


>「ネットワーク解除によるスリープ解除」がオンになっていると一般的にはコンソールで「wake re」でフィルタリングすると下記のような感じになります。

コンソールは流れてしまいましたが、ターミナルの電源ログのが1ヶ月程残っていたので、色々見直しています。

設定がオンになっているのを確認出来そうなキーワードがありましたら、教えて頂けますでしょうか?

 

ちなみに

>DarkWake due to EC.SleepTimer/SleepTimer: Using AC

のログは、報告して来た通り11日に単発、続いて15日からはスリープから4時間で入っていました。

11日の後も15日に症状が出るまで普通に長時間スリープさせて来ていたのですが…

何故、突然規則的に症状が出るようになってしまったのか謎です。


ログをちゃんと読める方なら判るかもしれませんが、11日以降の方が以前のものより、

区切りと区切りの間の情報量が増えているような…?程度で私にはサッパリです…


引き続き数日ログをとってサポートに相談してみようと思います。(おそらく再インストールの方向に?そうなるとログがとれないので)

あまりハイバネートを作動させるのは良く無いような事がありましたら、教えて頂ければ幸いです。

2015/08/20 03:11 mikemi への返信

コメントを幾つか。


• 私の理解では、セーフスリープとは、メモリの内容を永続ディスクに書き出す種類のスリープのことで、ディープスリープとは、セーフスリープの一つでメモリへの電力供給をカットするものです。hibernatemode > 0 でのスリープはセーフスリープとなり、特に hibernatemode = 25 では必ずディープスリープとなります。hibernatemode = 3 では、メモリへの電力供給が失われた場合のみ、ディスクに保存された hibernation image から復帰します。


この理解に従えば、いま議論の対象になっている autopoweroff は、メモリ内容をディスクに書き出して且つメモリへの電力供給をカットするので、正確にはディープスリープです。しかし、ディープスリープはセーフスリープの一つなので、セーフスリープであるといっても間違いではないです。



• 繰り返しますが、autopoweroff は hibernatemode の値とは関係のない独立した機能です。



• Wake reason = EC.SleepTimer のログが、スリープに入った 4 時間後(正確には autopoweroffdelay で指定された秒数後)に記録されているのならば、それは、通常のスリープをディープスリープに切り替えるためにシステムがタイマーをセットしてスリープを一時的に解除した、ということでしょう。前にふれた、スリープ中にある種の通信等を行なう機能は、デスクトップ機の場合は、OS X 10.9 以降が必要条件なので、そのためのスリープ解除は今回は関係ないです。訂正しておきます。


cf. Mac の Power Nap の機能について

https://support.apple.com/HT204032



• Wake reason = RTC によって2時間毎にスリープが解除される現象は、私の理解が正しければ、 mDNSResponder の替わりに OS X 10.10 で導入された discoveryd が定期的に multicast を飛ばそうとしているためです。従って、OS X 10.8.5 の環境では関係ないはずです。尚、「ネットワークアクセスによるスリープ解除」の on/off は、pmset -g で表示される womp の値の 1/0 に対応しています。



• autopoweroff によるディープスリープに問題があるとは思えません。又、mikemi さんの示された pmset の設定で、スリープに入った 4 時間後に autopoweroff が起こるとすれば、それは予想される通りであり、全く正常です。いままで autopoweroff が起こらなかったとすれば、前にも書きましたが、それは autopoweroff を妨げるような外部との通信があったから、ではないですか。Console.app で過去のログを調べれば判ると思いますが。



• 「サポートの人」のスキルは様々で、その見解が正しいとは限りません。



• 私の見解が正しいとも限りません…

2015/08/20 04:22 chandana への返信

>• Wake reason = RTC によって2時間毎にスリープが解除される現象は、私の理解が正しければ、 mDNSResponder の替わりに OS X 10.10 で導入された discoveryd が定期的に multicast を飛ばそうとしているためです。従って、OS X 10.8.5 の環境では関係ないはずです。


Wake on Demand 関連らしいのでOS X 10.6 の頃からあるはずです。ログの表記は多少違いがあるかもしれませんが。

Wake on Demand および Bonjour Sleep Proxy について - Apple サポート

2015/08/20 09:32 ni_ki への返信

昨夜もスリープさせてみて、今朝もハイバネーションの画面が出たのですが

4時間で動いたログはなく、起動直前にログが残っていました。

電源入り切りのメモによると、

13:33 入

13:38 切

23:01 入(ハイバネ画面

23:50 切

8:15  入(ハイバネ画面>現在時刻表示まで約15s

8:20 切


という感じなのですがログを見ると、朝の復帰直前にディープスリープが働いた?跡が残っています。

どういう意味なのでしょうか…


コンソールWake re検索でのログです。


2015/08/19 10:25:32.000 kernel[0]: Wake reason: EHC1

2015/08/19 13:33:37.000 kernel[0]: Wake reason: EHC1

2015/08/19 17:38:19.000 kernel[0]: Wake reason: EC.SleepTimer (SleepTimer)

2015/08/19 23:01:39.000 kernel[0]: Wake reason: EC.PME (User)

2015/08/20 8:14:31.000 kernel[0]: Wake reason: EHC1

2015/08/20 8:15:25.000 kernel[0]: Wake reason: EC.SleepTimer (SleepTimer)

2015/08/20 8:19:40.000 kernel[0]: Wake reason: EC.PME (User)

2015/08/20 8:20:48.000 kernel[0]: Wake reason: EHC1


>autopoweroff は hibernatemode の値とは関係のない独立した機能

という事は、今の現象の(少なくとも一部は)hibernatemode0設定とは必ずしも矛盾しないのですね。ありがとうございます。

autopoweroff の動作にしぼって考えても良いかも?


>いままで autopoweroff が起こらなかったとすれば、前にも書きましたが、それは autopoweroff を妨げるような外部との通信があったから、ではないですか。Console.app で過去のログを調べれば判ると思いますが。


今回に関しては、Wake reason: RTC (Alarm)含め、夜切った後〜朝の間にログはありませんでした。

(出して良いか判らない英数字は***で隠しました


2015/08/19 23:50:56.000 kernel[0]: AirPort_Brcm***::powerChange: System Sleep

2015/08/19 23:50:58.000 kernel[0]: LE is supported - Disable LE meta event

2015/08/19 23:50:58.000 kernel[0]: IOThunderboltSwitch<0xffff***>(0x0)::listenerCallback - Thunderbolt HPD packet for route = 0x0 port = 11 unplug = 0

2015/08/19 23:50:58.000 kernel[0]: IOThunderboltSwitch<0xffff***>(0x0)::listenerCallback - Thunderbolt HPD packet for route = 0x0 port = 12 unplug = 0

2015/08/20 8:14:31.000 kernel[0]: AppleThunderboltNHIType2::waitForO*** - retries = 7

2015/08/20 8:14:31.000 kernel[0]: Wake reason: EHC1

2015/08/20 23:24 mikemi への返信

mikemi さんによる書き込み:


という感じなのですがログを見ると、朝の復帰直前にディープスリープが働いた?跡が残っています。

どういう意味なのでしょうか…


2015/08/20 8:14:31.000 kernel[0]: Wake reason: EHC1

2015/08/20 8:15:25.000 kernel[0]: Wake reason: EC.SleepTimer (SleepTimer)

2015/08/20 8:19:40.000 kernel[0]: Wake reason: EC.PME (User)

2015/08/20 8:20:48.000 kernel[0]: Wake reason: EHC1

これが正確に記録されたものかどうかは全体をみないと判断つかないのでなんとも言い難いです。稀にタイムスタンプがおかしいこともあります。

ログだけ見れば8:19:40 にユーザーがスリープを解除したように見えますね。


それで私のところのiMac(27-inch, Late 2009)OS X 10.10.4 で「ネットワークアクセスによるスリープ解除」をOFF にして確認したところ、件のログが記録されました。私はLAN からこのMac を整備点検することがあるので、購入後今まで「ネットワークアクセスによるスリープ解除」をON にしておりました。なのでよもや初期設定でディープスリープするとは存じあげませんでした。

4 時間以上スリープするとディープスリープするのは正常な動作のようです。いままでしなかったということは何かがスリープを4 時間以内に解除していたか、「ネットワークアクセスによるスリープ解除」がON だったということはないでしょうか。それとiPhone をiMac のスリープ中に接続 or 切断するとスリープ解除されますので、そこから4 時間のカウントが始まると考えられます。

なおiMac(5K, 27-inch, Mid 2014)には初期設定でこの能力はないようです。搭載しなくてもヨーロッパの基準がクリアできたのでしょうね。きっと。

2015/08/21 00:24 ni_ki への返信

ni_ki さん、訂正ありがとうございます。


私は、OS X 10.6.8 を使っているのですが、長時間スリープさせる事がほとんどない(シャットダウンさせる)ので気づきませんでした。詳しくログを調べたところ、Wake reason = RTC が 2 時間ごとに記録されている部分を発見しました。Bonjour Sleep Proxy に対応する機器は一切使っていませんが、womp = 1 となっているために、その絡みで定期的なスリープ解除が起こっているようです。勉強になりました。

2015/08/21 09:12 chandana への返信

いつもありがとうございます。

判った事は、hibernatemodeの設定に関わらず

「ネットワークアクセスによるスリープ解除」がOFFだと4時間でディープスリープする。

・ONにしていると、2時間ごとに裏でスリープ解除される→ディープスリープしない

私の場合、問題が起きたのは、「ネットワークアクセスによるスリープ解除」をONにしているのに、ディープスリープするようになってしまった。

→ネットワークアクセスによる定期的なスリープ解除がされなくなってしまった?

またディープスリープに入るタイミングが4時間の法則があてはまらないケースがある。


今朝も朝にログが残っていました。>タイムスタンプに関しては、起動直後PCの時間と合わせてチェックしたるのであまり狂いは無いと思います。

ログを取り始めてからは夜以外は法則が働いていたので、もしかして日付が変わる前と後で違う?とも思うので、

可能だったら今夜は日付が変わってからスリープさせてみます。


あとついでで恐縮なのですが、以下のログの意味が判ったら教えていただけますでしょうか?

Wake reason =EC.PME (User)

com.apple.time[138]: Interval maximum value is 946100000 seconds (specified value: 9223372036854775807).(昨日の朝コンソールに膨大にログが…

2015/08/21 09:52 mikemi への返信

リターンで修正前を送ってしまった上、編集出来なくなってしまいました…(苦笑

判りにくい所があったらすいません。


一応今朝のログです。

2015/08/20 21:03:10.000 kernel[0]: Wake reason: EHC1

2015/08/20 22:59:56.000 kernel[0]: Wake reason: EHC1

2015/08/21 8:08:39.000 kernel[0]: Wake reason: EHC1

2015/08/21 8:09:05.000 kernel[0]: Wake reason: EC.SleepTimer (SleepTimer)

2015/08/21 8:48:38.000 kernel[0]: Wake reason: EC.PME (User)

09分に動いてるのは、おそらく、家人が接続していたiPhonを外したせいと思います。

2晩続けて4時間でスリープしていないので、出来そうな時日付変更後にスリープ開始を試してみます。


どちらにしてもディープスリープの症状は固定化してしまって、

原因もプリンタのドライバの再インストールがきっかけだったとしてアクセス権の修復等で直らないものだとドライバを消してどうなるものでもなさそうなので

ある程度ログを取ったら、対症療法として4時間以上スリープさせない(夜はシャットダウンさせる)か、症状を受け入れて過ごし、

時期を見て、OSの再インストールを試みるのが無難な解決策になりそうですね(再インストールやTime Machineからの復元をした事が無いので、想像するだけで緊張します…

2015/08/22 20:45 mikemi への返信

mikemi さんによる書き込み:


どちらにしてもディープスリープの症状は固定化してしまって、

個人の生活に関わるので「ちょっと」だけ遠慮していたのですが、スレ主さんは結構規則正しい生活をされているご家族のようですね。

それで、

2015/08/21 8:08:39.000 kernel[0]: Wake reason: EHC1

2015/08/21 8:09:05.000 kernel[0]: Wake reason: EC.SleepTimer (SleepTimer)

この「EHC1」の前のログは何でしょか?

「wake re」はMac がスリープ解除されたかは確認できるのですが、いつスリープしたかは確認できません。なので「8:08:39.000」の前のログがみたいです。

2015/08/22 23:20 ni_ki への返信

いつもありがとうございます。


>「8:08:39.000」の前のログがみたいです。

こちらでよろしいでしょうか?手元メモでは20日23:21にスリープになっています。(一部***で略しました


2015/08/20 23:21:59.000 kernel[0]: AirPort_Brcm***::powerChange: System Sleep

2015/08/20 23:22:01.000 kernel[0]: LE is supported - Disable LE meta event

2015/08/20 23:22:01.000 kernel[0]: IOThunderboltSwitch<0xffffff80***>(0x0)::listenerCallback - Thunderbolt HPD ***

2015/08/20 23:22:01.000 kernel[0]: IOThunderboltSwitch<0xffffff80***>(0x0)::listenerCallback - Thunderbolt HPD ***

2015/08/21 8:08:39.000 kernel[0]: AppleThunderboltNHIType2::waitForOk*** - retries = 10

2015/08/21 8:08:39.000 kernel[0]: Wake reason: EHC1


よろしくお願い致します。


あと昨夜は日付が変わってからスリープさせたのですが、今朝はハイバネーション画面になりませんでした。

(Wake reログにもWake reason: EHC1だけ)

日中は4時間以上スリープさせず、例の画面にもならなかったので、引き続き様子を見て行きます。


また8/1~8/19のターミナルのログのHibernateStatsを見ていたのですが

2015/08/19 23:01:48 JST HibernateStats hibmode=0 standbydelay=4200 rd=2621 ms


これが、コンソールの以下ログ時間とかぶるので、

2015/08/19 23:01:39.000 kernel[0]: Wake reason: EC.PME (User)


ハイバネーション画面を確認した時に残されたログだと思ったのですが、

これに似たログが11日には夜中まで9回も残っていて(頻度が高かったので、4時間スリープとは関係無いようです)

17日も2回あったので比較してみた所、片方はハイバネーション画面になった時、もう片方は不明の2パターンある事が判りました。


2015/08/17 21:56:36 JST Wake Wake from Standby due to EC.PME/User: Using AC ** secs

2015/08/17 21:56:36 JST HibernateStats hibmode=0 standbydelay=4200 rd=3467 ms

↑ハイバネート復帰時


2015/08/17 22:05:19 JST WakeRequests Clients requested wake events: None

2015/08/17 22:07:25 JST Wake Wake due to EHC1/HID Activity: Using AC

2015/08/17 22:07:25 JST HibernateStats hibmode=0 standbydelay=4200 rd=3467 ms

↑??11日にはこれが30分程度〜数時間間隔をあけて8回分記録


意味無いかも判りませんが、一連の現象に連動している症状なので念のため。

2015/08/22 23:49 mikemi への返信

追記:前記事を書いた後で気がつきましたが、19日までは頻度が低かったのですが、

20日以降からはかなりログがあって(今日も以下のパターンもありました。

2015/08/21 8:08:58 JST WakeRequests Clients requested wake events: None

2015/08/21 8:09:07 JST DarkWake DarkWake due to EC.SleepTimer/SleepTimer: Using AC 0 secs

2015/08/21 8:09:07 JST HibernateStats hibmode=0 standbydelay=4200 rd=2790 ms


今日のだけざっくり見た感じだと、Wake reason: EHC1のログと一致しているようです。

多分11日の大量ログも同じか似た状態だったのかもしれません。

ハイバネーションモードになった原因について

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