追記）
ATOKを使わなくても、やはりハングした。
バグレポートをしておいた）
Apple developer networkを使って、英語アカウントから2012/12/20にバグをレポートしておいた。
Problem ID: 12921400 である。そのうち、修正版がでると期待したい。
原因はtalagent)
talagentというプロセス(daemon) がwindowを制御しようとし失敗して、膨大なメッセージをはき続けており、この状況でGUIを制御しようとすると軒並み巻き添えを食らっていた。Mail, Evernote, task managerなど軒並みこれに絡んでハング。この章の最後にsystem.logの該当部分を引用する。
たまたま、terminalが起動できた。そして、このtalagentをkill -9 で殺したところ、ATOK、Chrome、Activity monitorなど、ハングアップしていたものが一気に復活した。
昨日、何度かOS-Xがハングしているが、system.logをみると全てtalagentが以下のようにwindowを操作しようとして、エラーを起こして、システムをハングさせている。
talagent[230]: CGSSetWindowSendExposed: Invalid window 0x35
talagent[230]: CGSBindSurface: Invalid window 0x2c
もう少しtalagentについて調べ、以下の実験が上手くいったら別投稿にまとめる。
それにしても、/var/log/system.logには膨大量のエラーメッセージがはき続けられている。OS-X Mountain Lionは、極めて未完成なままリリースされているOSということだろう。。
talagentとは）
http://forums.macrumors.com/archive/index.php/t-1138868.html によると、以下の様にあり、
talagent -- talagent is a helper agent for the Transparent App Lifecycle feature.
DESCRIPTION
The talagent tool provides services related to the Transparent App Life-cycle feature.
上記で言われている the Transparent App Lifecycle というのは、
http://bit.ly/Zg8TI4 に説明がある。マシンが落ちても、データやウィンドウの位置を含めて以前の状態に復活するということだと思う。なので、時々動いて状態を待避していれば十分。多分状態の待避には1分もかからないので、5分ごとに見付けてkillしても問題はないと思う。talagentは、killされても直ぐには再起動しないのだが、かりに相当時間が掛かって再起動したとしても、killするほうと同期しなければ、talagentは平均2.5分は生きているわけなので、とりあえず状態待避には問題はなさそうである。そもそもcrashしなければ、talagentなど必要はない。。
talagentは不安定になったOS-X Lionの途中で導入された、ないしは、改造され不安定になって、そのまま放置されているのかも知れない。
それにしても、状態復活のためのdaemonの性でシステムがハングするというのは、これまたお粗末。。
talagentの動作）
talagentは殺しても、以下のようにしばらくすると復活する。
Satoshi-MacBA:log$ ps -e | grep talagent
3726 ?? 0:00.86 /System/Library/CoreServices/talagent
5387 ttys000 0:00.00 grep talagent
Satoshi-MacBA:log$ kill 3726 ＜＜ 殺した
Satoshi-MacBA:log$ ps -e | grep talagent
5389 ttys000 0:00.00 grep talagent ＜＜ もういない
Satoshi-MacBA:log$ ps -e | grep talagent
5391 ttys000 0:00.00 grep talagent ＜＜ もういない
Satoshi-MacBA:log$ ps -e | grep talagent
5393 ?? 0:00.07 /System/Library/CoreServices/talagent ＜＜復活
5400 ttys000 0:00.00 grep talagent
launchdで 処理する)
http://bit.ly/YfOCky のようにMac OS-X Lion系にはinit.dがない。
ホームディレクトリにある Library/LaunchAgents に、XMLで記述ファイルをつくれば、自動的に実行してくれる。
http://bit.ly/1ggKTwD にサンプルがある。
~/Library/LaunchAgents/com.satoshi.killtalagent.plist として以下のファイルを作ったところ定期的に実行される。実行されていれば、/tmp/Satoshi-KillTalagent.out に以下のメッセージが追記される。
Killing talagent at Mon Oct 14 22:19:58 PDT 2013
これが一番簡便である。StartIntervalが1800=1800秒=30分なので、30分に1回実行される。
~/Library/LaunchAgents/com.satoshi.killtalagent.plist の記述は以下のようにする。
--
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.satoshi.killtalagent</string>
<key>ProgramArguments</key>
<array>
<string>/Users/matsushi/scripts/kill-talagent.sh</string>
</array>
<key>Nice</key>
<integer>1</integer>
<key>StartInterval</key>
<integer>1800</integer>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/tmp/Satoshi-KillTalagent.err</string>
<key>StandardOutPath</key>
<string>/tmp/Satoshi-KillTalagent.out</string>
</dict>
</plist>
--
/Users/satoshi/scripts/kill-talagent.sh は以下のようなシェルスクリプトである。
--
#!/bin/sh -f
echo Killing talagent at `date`
killall -c talagent
--
perl スクリプトでやると）
5分に一度ぐらい起きだして、talagentを探してkillするcron scriptで解決するのではと思う。
昔使っていたperl scriptは以下の通り。
これをバックグラウンドで動かしていた。
オプションは、
-vでverbose (これを付けないとメッセージは何も出ない)
-t 数字 でsleepの秒数指定 (デフォルトで300秒)
-dでデバッグモードである。
このスクリプトをバックグラウンドで動かしておくことで、Mac OS-Xがハングアップしても、5分以内に復活してこれば成功である。
状況）
まる2日動かしてもハングしないし、system.logにはtalagentのエラーメッセージは吐かれない。多分talagentがメモリーリークしていて、長期に渡り動かすと、段々おかしくなるのであろう。つまり、ハングして復旧するためにkillするのではなく、メモリリークを起こすまえに再起動すればよいので、30分毎に再起動でも構わないはず。。ということで、30分間隔にタイマを変えて試しているが、多分これでも大丈夫である。
使い方)
以下を、例えば kill-talagent.pl というファイルに書き込み。
chmod +x kill-talagent.pl
kill-talagent.pl &
で起動しておけばよいはずである。
スクリプトのソースコード)
---
#!/usr/bin/perl
use Getopt::Long;
$prog = $0;
$sleeptime = 5 * 60; # default 5 minutes
GetOptions('verbose!' => \$verbose, 'debug!' => \$debug, 'time=i' => \$sleeptime);
while (1) {
open(P, 'ps -e | grep talagent |') || die "Cannot creat pipe\n";
while () {
# print if ($debug);
s/^\s+//;
@f = split(/\s+/);
my $pid = $f[0], $pname=$f[3];
if ($pname =~ "/talagent") {
if ($debug) {
printf("%s: Found %s: ps $pid ..\n", $prog, $pname, $pid);
system("ps $pid");
} else {
printf("%s: Killing: %d %s ..\n", $prog, $pid, $pname) if ($verbose);
system("kill -9 $pid");
}
}
}
printf("%s: sleeping: %d sec\n", $prog, $sleeptime) if ($verbose || $debug);
sleep($sleeptime);
}
--
状況）
丸2日使っているが、ハングしていない。従来は、1日に2-3度強制リブートしていた。また、Thunderbolt displayにクラムシェルモードで接続したり、LCDにdvi接続したときに、ハングする現象も解決した。
system.logをみても、talagentはエラーを吐いていない。
ということは、talagentのエラーはメモリーリークなどが原因の可能性が有り、長期に渡り動作させ続けなければ問題はおきない。ウィンドウ状態の永続化を有効に実現するには、5分に一度よりはもう少し長い間隔でkillしたほうが良いであろう。つまりハングしたら復活させるためにkillするのではなく、ハングするような不正動作に陥る前にtalagentを再起動しするという手法である。
もうしばらく使って問題が無ければ、Appleにバグ報告をして、killする間隔を30分程度に伸ばして試してみたい。
cron化）
http://borg4.vdomains.jp/~goro/diary/2011/1252 や
http://d.hatena.ne.jp/zariganitosh/20090308
にやり方の紹介がある。OS-Xでは、cronではなく、launchdはxmlで書くようである。
talagentが原因であると判明したsystem.logの該当部分)
---- /var/log/system.log より ----
Dec 18 03:17:45 Satoshi-MacBA com.apple.launchd.peruser.501[198] (com.apple.accountsd[2592]): Exited: Killed: 9
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: memorystatus_thread: idle exiting pid 2601 [QuickLookSatelli]
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: Wake reason: EC.ACAttach EHC2 (Maintenance)
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: AirPort_Brcm43xx::powerChange: System Wake - Full Wake/ Dark Wake / Maintenance wake
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: Previous Sleep Cause: -113
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: The USB device HubDevice (Port 1 of Hub at 0xfa000000) may have caused a wake by issuing
a remote wakeup (2)
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: TBT W (1): 0 [x]
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: memorystatus_thread: idle exiting pid 2592 [accountsd]
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: The USB device USB 2.0 Hub (Port 3 of Hub at 0xfa100000) may have caused a wake by issui
ng a remote wakeup (3)
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: AppleUSBMultitouchDriver::checkStatus - received Status Packet, Payload 2: device was re
initialized
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: The USB device USB 2.0 Hub (Port 4 of Hub at 0xfa130000) may have caused a wake by issui
ng a remote wakeup (3)
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: The USB device HubDevice (Port 3 of Hub at 0xfa134000) may have caused a wake by issuing
a remote wakeup (3)
Dec 18 03:17:46 Satoshi-MacBA com.apple.launchd[1] (com.apple.audio.ComponentHelper[2571]): Could not terminate job: 3: No such process
Dec 18 03:17:46 Satoshi-MacBA com.apple.launchd[1] (com.apple.audio.ComponentHelper[2571]): Using fallback option to terminate job...
Dec 18 03:17:46 Satoshi-MacBA com.apple.launchd.peruser.501[198] (com.apple.scopedbookmarksagent.xpc[2572]): Exited: Killed: 9
Dec 18 03:17:46 Satoshi-MacBA com.apple.launchd[1] (com.apple.audio.ComponentHelper[2537]): Exited: Killed: 9
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: The USB device GCS932UBV1.1.10 (Port 1 of Hub at 0xfa134300) may have caused a wake by issuing a remote wakeup (3)
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: HID tickle 682 ms
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: memorystatus_thread: idle exiting pid 2572 [ScopedBookmarkAg]
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: memorystatus_thread: idle exiting pid 2571 [com.apple.audio.]
Dec 18 03:17:46 Satoshi-MacBA kernel[0]: memorystatus_thread: idle exiting pid 2537 [com.apple.audio.]
Dec 18 03:17:45 Satoshi-MacBA talagent[230]: CGSSetWindowSendExposed: Invalid window 0x2d
Dec 18 03:17:46 Satoshi-MacBA WindowServer[105]: CGXDisableUpdate: UI updates were forcibly disabled by application "SystemUIServer" for over 1.00 seconds. Server has re-enabled them.
Dec 18 03:17:46 Satoshi-MacBA hidd[82]: MultitouchHID: device bootloaded
Dec 18 03:17:47 Satoshi-MacBA com.apple.launchd.peruser.501[198] (com.apple.coreservices.appleid.authentication[2529]): Exited: Killed: 9
Dec 18 03:17:47 Satoshi-MacBA com.apple.launchd[1] (com.apple.audio.SandboxHelper[2536]): Exited: Killed: 9
Dec 18 03:17:47 Satoshi-MacBA WindowServer[105]: handle_will_sleep_auth_and_shield_windows: no action for lock state 1
Dec 18 03:17:47 Satoshi-MacBA kernel[0]: memorystatus_thread: idle exiting pid 2536 [com.apple.audio.]
Dec 18 03:17:47 Satoshi-MacBA kernel[0]: memorystatus_thread: idle exiting pid 2529 [AppleIDAuthAgent]
Dec 18 03:17:47 Satoshi-MacBA talagent[230]: CGSBindSurface: Invalid window 0x2c
Dec 18 03:17:48 --- last message repeated 2 times ---
Dec 18 03:17:47 Satoshi-MacBA talagent[230]: CGSSetWindowSendExposed: Invalid window 0x35
Dec 18 03:17:47 Satoshi-MacBA talagent[230]: CGSBindSurface: Invalid window 0x2c
Dec 18 03:17:48 --- last message repeated 3 times ---
Dec 18 03:17:47 Satoshi-MacBA talagent[230]: CGSSetWindowSendExposed: Invalid window 0x2d
Dec 18 03:17:47 Satoshi-MacBA talagent[230]: CGSBindSurface: Invalid window 0x2c
Dec 18 03:17:48 --- last message repeated 3 times ---
---- talagentを殺したあと
Satoshi-MacBA:log$ ps -ael | grep 230
501 230 198 4004 0 53 0 2599660 7808 - S 0 ?? 26:47.77 /System/Library/CoreServices/talagent
Satoshi-MacBA:~$ kill -9 230
Satoshi-MacBA:log$ ps -ael | grep talagent
501 3726 198 4004 0 49 0 2508904 8872 - S 0 ?? 0:00.17 /System/Library/CoreServices/talagent
---
元記事）
2011年秋にかったMacbookAir 13 inch (4GB RAM, 256GB SSD) のMac OS-X Mountain Lion (10.8.2) ならびに、その前のOS-X Lionの後半から、ブラウザがどれも不安定である。状況は、
- Google Chrome: 一日に1度は、ハングする
- Firefox: 文字入力ウィンドウがめちゃくちゃになる。blogが書けない
- Safari: 突然Safariがクラッシュする。リカバリのplug inをいれてあるが、restartしたときに意味不明なwindowにリカバリする。
下の絵に引用した、FreeRAM boosterで、いつも1GBくらいのメモリを回収しており、空きメモリを表示しているので、メモリ不足が原因ではない。
Chromeの原因がなんとなく判明)
やはり、使い勝手が良いのでGoogle Chromeに戻した。すると、日に2〜3度Macがフリーズする。Chromeがクラッシュするのではなくて、虹色のくるくるマークがでて、システムが無反応になり、強制電源オフするしかなくなる。
システムテストやらdisk checkも正常。Chromeを消去して、再インストールしてみたあとで、/var/log/system.log (以下のスクリーンショットが該当部) をみたら、原因がわかった。上から3行目（青色部）でJUST SYSTEMのATOKがbus errorを起こして、エラーダンプしたりしたあと、17:32分から無反応になっている。
 |
| system.log |
その後、下から6行目の17:37分にrebootのメッセージがでている。
その後、膨大なエラーも出ているのだが、特に talagent[230]: CGSSetWindowSendExposed: Invalid window 0x35 というものが膨大にでている。Objective-CのAPIの使い方か、ライブラリにバグがある模様。おそらく、AppleがOS-X 10.8.2で勝手にAPIを変えたので、ATOKが時々死ぬのだろう。
でもやはり）
知人は、Google 変換でChromeを使っているが、やはりよく、システムがハングするという。その状況で調べてみる必要はある。Google変換で、どうなるのかも試してみたい。少し試してみたが、私は変換・無変換などでキーをカスタマイズしているのだが、一旦、英数になると、かなに戻らない状況。
ATOK Passport)
ATOKは賢いし、ATOK Passportだと月300円で、iOSを除く自分持ちの全ての端末(win, linux, Mac, Android) にインストール出来、ユーザ辞書や学習履歴も無料のJust drive経由で共有、時事事象も逐次更新されるので好きなのだが。また、日本のソフトメーカで頑張っているJUST Systemも応援したい。
日本はやっぱりIT辺境）
OS-X 10.8.2の標準メイラが、i-modeメイルからのメイルで完全に文字化けしていたのにリリースしていたり、日本のApple地図がめちゃくちゃだったりということを考えると、Appleも米国の製品ならフィードバックはかかるが、日本Appleは無視され、日本のユーザに対するベータテストはほとんどやられていないのではと思われる。
その点では、IMEが悲惨なMSもダメだし、Linuxに浮気するしかないかも。。
ただし、Mac OS-Xは、BSD unix系であり、勝手が分かっているので解析がしやすい。
投稿
