むにゃむにゃ...

Apple タイムサーバー(time.apple.com)障害

ikiuo — Wed, 28 Aug 2024 14:44:05 +0000

タイムサーバーの時刻がおかしい？

システム設定 > 一般 > 日付と時刻

「自動的に設定」は有効、「タイムサーバー」は Apple (time.apple.com.) だけど、「時刻がずれる」症状に遭遇した方が少なくないようです。ネットワーク通信に問題ないならば「タイムサーバーの時刻が狂ってる」と判断するのは仕方ないでしょう。

しかし、タイムサーバーから時刻が取れない状況が続くと、Macの内蔵時計のままになっています。設定上はタイムサーバーの時刻ですが、実態はMacの内蔵時計かもしれないのです。内蔵時計も実用的な精度で時間が進むので、気付くまでに日数を要するでしょう。

このとき、「内蔵時計の時刻」を「タイムサーバーの時刻」と誤認して「タイムサーバーの時刻が狂ってる」と判断しても、他所と状況が違うので混乱することになります。

時刻が取れない状況が続く？

time.apple.com は IP アドレスに変換すると下の表になります。IP アドレスに対する色分けが取得の可否です。

time.apple.com に出現するアドレスと逆引きしたホスト名

IPv4アドレス	IPv6アドレス	逆引きしたホスト名
17.253.68.123	2403:300:a0c:3000::1e2	jptyo5-ntp-003.aaplimg.com
17.253.68.251	2403:300:a0c:4000::1e2	jptyo5-ntp-004.aaplimg.com
17.253.68.253	2403:300:a0c:4000::1f2	jptyo5-ntp-002.aaplimg.com
17.253.114.125	2403:300:a16:3000::1f2	krsel6-ntp-001.aaplimg.com

krsel6-ntp-001.aaplimg.com (17.253.114.125) は出現しません。

2024/08/28時点での情報です。

IPv6 通信ができない環境では、タイムサーバーへの接続が IPv4 で時刻が取れます。使われる IP アドレスは青色です。

IPv6 通信ができる環境では、使われる IP アドレスは赤か黄(暗)です。青(IPv4)は使用されません。ホスト名 jptyo5-ntp-* (赤)はすべて応答がありません。唯一、応答があるのはホスト名 krsel6-ntp-* ですが

　　Mac → [中継] → krsel6-ntp-*

　　Mac ← [中継] ← krsel6-ntp-*

の通信が約1秒で終わらないとタイムアウト(エラー)になります。タイムアウトになるかならないかは [中継] 次第です。ホスト名から jptyo5-* は日本･東京で、krsel6-* は韓国ソウルでしょう。krsel6-* は jptyo5-* よりネットワーク的に条件が厳しくなります。(特に最初の通信)

krsel6-* から時刻を取れるかどうかは運次第となって

時刻が取れない状況が続く
時刻は内蔵時計だけなので、ずれ続ける
時刻が時々取れる(その1)
ずれたり直ったりする
時刻が時々取れる(その2)
ずれに気付かない(見た目は正常動作)
時刻が取れる
正常動作

の何れかの状況になりますが、どの状況になるのか確定しないので、とても厄介です。

通信が IPv4 なのか IPv6 なのか？

Google の IPv6 通信テストがあるので、チェックしてみてください。

インターネットの未来に向かう準備はできていますか？
お使いの接続方法をテストできませんでした。もう一度試すか。しばらくお待ちください。IPv6 への対応状況を確認しています... 既に IPv6 を使用しているようです。インターネットの未来へようこそ！問題は検出されませんでした。お使いの接続方法は IPv6 への対応が完了していませんが、IPv6 をサポートしているウェブサイトは問題なく閲覧できるはずです。お使いの接続方法は IPv6 への対応が完了していないようです。原因としては、お使いのホームルーター、オペレーティングシステム、または ISP の問題が考えられます。 IPv6 について詳しくはこちら、World IPv6 Launch について詳しくはこちらをご覧ください。

ESET Cyber Security の不具合(V6.3まで)

ikiuo — Wed, 28 Feb 2018 01:05:23 +0000

以前 Mac OS X が不安定だと思っていたが、その原因は ESET Cyber Security Pro だった。

コンソールアプリケーションで .crash ファイルを確認すると、

と、こんな感じでクラッシュが多発していた。

ESET プロセスのクラッシュ直後に

Safari や Chrome などのブラウザで接続エラーになる
特定サイトのみエラーになる症状にも遭遇
メールでアカウントエラーになる
後に「修復されたメッセージ」フォルダが作られていた
同期を行っているサービスがエラーになる
実行プログラムのライブラリファイルの読み込みエラー
OS X の異常終了(カーネルパニック)が起きた
接続していた iPhone 6s のホームボタンが熱くなった

などの症状に遭遇している。まるで Mac OS X が不安定な感じだが、ECSP がカーネルに悪影響を及ぼす（カーネル拡張処理中に異常終了する）ので様々な症状が出ていたようだ。

クラッシュ時の診断ファイルを見つつ分析して、動作が不安定となるバグを特定した。このバグは初期バージョンから V6.3 まで含まれていて V6.4 で修正された。数日に一回発生していた ESET プロセスのクラッシュは、半年で数回に激減した。V6.5 になってから一度も遭遇していない。

■多発するクラッシュの技術的な詳細

沢山ある .crash ファイルを眺めていると、バックトレース中の RefObje::Unref() が目に付いた。その先には参照が終わったであろうオブジェクトのデストラクタ[Object::~Object()形式の関数]がある。そこからメモリ解放に失敗するなど、メモリ内容の破壊が原因となっているようだった。

デストラクタの処理中なので、同じオブジェクトが別のスレッドで既に破棄されていた場合が考えられる。これを仮定してバックトレースを見ると、呼び出し元である RefObj::Unref() がスレッドセーフではない可能性に気付いた。

RefObj::Unref() はオブジェクトの参照カウントをデクリメントして０ならデストラクタを呼び出す、短くて簡単なプログラムだと名前から推定できる。ライセンス違反（その旨はサポートにも話をしてある）だが逆アセンブルして調査する事にした。プログラムを見ていくと、やっぱりスレッドセーフになっていなかった。

RefObj::Unref() での参照カウントのデクリメントと結果判定は

move $-1, regA ;# regA = -1

lock ;# // 直後の命令はアトミック操作

xaddl regA, (参照カウント) ;# regA = 参照カウント --

move (参照カウント), regA ;# regA = 参照カウント

test regA, regA ;# (0 == regA) ? ...

こんな風になっていてマルチスレッドプログラミングにおけるバグの典型

;# 参照カウントは 2 とする

move $-1, regA ;# regA = -1

lock ;# // 直後の命令はアトミック操作

xaddl regA, (参照カウント) ;# regA = 参照カウント --

;# 参照カウントは 1 に更新された
;#** ここでスレッド切替の割り込みが発生する
;# 切り替わったスレッドが同じオブジェクトの RefObj::Unref() を呼び出す
;# さらに参照カウントが更新されて 0 になる
;# 参照カウントが 0 なのでデストラクタを呼び出す
;#** スレッドの処理が戻される

move (参照カウント), regA ;# regA = 参照カウント

;# 参照カウントは 1 の予定だが 0 になっている
test regA, regA ;# (0 == regA) ? ...

;# 参照カウントが 0 なので再度デストラクタを呼び出す
;# メモリ内容を破壊してクラッシュに至る

になっている。 C++ による記述だろうから、アトミック操作と判定処理で別々のメモリアクセスになっているのだろう。アトミック操作により参照カウントは RefObj::Unref() を呼び出した回数に応じた値で更新されるが、判定時に他のスレッドを同じ値と判断する可能性がある。運が悪いと、二つのスレッドから同じオブジェクトのデストラクタが各々呼び出されてしまう。クラッシュする場合はプログラムが異常終了するが、クラッシュしない場合は、メモリ内容を破壊したまま動作するので何が起きるか分からない。

V6.1 はコンパイル時の最適化オプションが入っておらずシンボルも残っていた。どうやらデバッグ版でビルドしたバイナリをリリースしていたようだ。お陰で RefObj::Unref() という名前の関数にあるバグを特定できた。

■クラッシュログ

サポートからの最初の回答は「正常に動作しています」だった。問い合わせ内容にクラッシュログを引用し、customer_info ログにクラッシュログが含まれていたのに「正常動作」と判断している。クラッシュログを見ていないことが分かった。サポートの技術担当の知識不足もあるだろうけど、クラッシュログ確認を指示されていないことも分かる。本来は ESET社からクラッシュログの収集指示が出ていないといけないが、不具合調査におけるクラッシュログの重要性を知らない技術担当でいいのか？と、基本的なことから問い合わせしないといけなかった。

不具合の状況について提出した資料では、動作と症状の詳細解説と修正方法を示しておいた。サポートの技術担当は理解したという返事が早々にあったが、そこからESET社が「内容が正しいようだ」と回答されるまで約三ヶ月かかっている。動作を理解できたのか非常に怪しいが修正された。経緯から ESET Cyber Security のプログラム担当はスキル不足と判断するしかないので、スキルアップをお願いしておいた。

原因調査ではクラッシュログは重要な情報だから、OSでは「○○が予期しない理由で終了しました」でレポートするときの送信内容になっている。

macOS Sierra - Mission Control の問題

ikiuo — Thu, 10 Nov 2016 02:51:52 +0000

■ Mission Control の挙動

選択するウインドウの位置は

(1) Mission Control を起動した状態

(2) デスクトップを選択可能にした状態

の二段階で移動します。

■ 問題１：ウインドウ選択の枠がズレた場所に出る

二段階で移動した後、選択の枠が一段階目の位置に出ることがあります。

再現手順は

　　1. Magic Trackpad を使う

　　2. マウスカーソルを画面上端の中央付近へ

　　3. Mission Control をジェスチャー (３本指で上) で起動する

　　　※スッっと一瞬だけ触れて起動します

　　4. Mission Control 開始から約 0.5 秒以内にマウスカーソルを移動する

　　　※デスクトップを選択可能な状態にします

　　5. ウインドウを選択する

とします。

■ 問題２：選択したウインドウが固定される

選択の枠がズレた状態でウインドウを選択すると、そのウインドウが画面上に固定され移動もサイズ変更も出来なくなることがあります。

再現させるには選択の枠がズレた状態を作りますが、最初の配置も重要です。ここでは Mission Control を開始する前の配置は[デスクトップ1]のような位置・サイズで開始しました。

左のターミナルをクリックして選択したら、元の位置に戻らずウインドウが固定されました。こうなると、ウインドウを移動しようと操作しても移動しません。サイズを変更しようとすると、

となって、変更できません。代わりに中の表示が拡大されています。サイズ変更操作を続けて、もう一度 Mission Control を実行してみると、

となっていて、[デスクトップ1] では左側のターミナルが小さくなっています。これが本来の位置とサイズのようです。さらに、この Mission Control 中に左側のターミナルをドラッグして少し移動すると、正常な位置・サイズに戻ってウインドウの固定は終了しました。

■ アップデート待ち

Apple サポートの窓口の方が再現確認しています。誰でも再現可能なので修正されるのは時間の問題でしょう。あとはアップデートを待つだけです。

BLOG

Tue, 08 Nov 2016 14:32:10 +0000

WORKS

Tue, 08 Nov 2016 14:32:10 +0000

move	$-1, regA	;# regA = -1
lock		;# // 直後の命令はアトミック操作
xaddl	regA, (参照カウント)	;# regA = 参照カウント --
move	(参照カウント), regA	;# regA = 参照カウント
test	regA, regA	;# (0 == regA) ? ...

;# 参照カウントは 2 とする
move	$-1, regA	;# regA = -1
lock		;# // 直後の命令はアトミック操作
xaddl	regA, (参照カウント)	;# regA = 参照カウント --
;# 参照カウントは 1 に更新された ;# ここでスレッド切替の割り込みが発生する ;# 切り替わったスレッドが同じオブジェクトの RefObj::Unref() を呼び出す ;# さらに参照カウントが更新されて 0 になる ;# 参照カウントが 0 なのでデストラクタを呼び出す ;# スレッドの処理が戻される
move	(参照カウント), regA	;# regA = 参照カウント
;# 参照カウントは 1 の予定だが 0 になっている
test	regA, regA	;# (0 == regA) ? ...
;# 参照カウントが 0 なので再度デストラクタを呼び出す ;# メモリ内容を破壊してクラッシュに至る