12月21日
#DECODE failed to resolve UUID:・・を抑止した方法
High SierraからMojaveにアップグレードした後、/var/log/system.log.に#DECODE failed to resolve UUID: [pc:0x... ns:0x... flags:0x... main:... pid:491]というログが大量に出力されるようになり困っていました。この記事ではこの#DECODEログを抑止する方法をご紹介しています。
Mojave 10.14.2を使っているとこのログが出力されます。
#DECODE failed to resolve UUIDを吐き出している大元は、JapaneseIMです。JapaneseIMはMojave標準の日本語入力機能を実現しているプログラムだと思います。PIDからJapaneseIMと推測できます。
ログ出力をよく見てみると２つのPID(プロセスID)があることに気がつきます。logd[ PID ] : #DECODE failed to resolve UUID: .... pid:491 ]（青い数字がPIDです）
はじめのPIDはlogd(/usr/libexec/logd)です。２つの目のPIDは、JapaneseIM(/System/Library/Input Methods/JapaneseIM.app/Contents/PlugIns/JapaneseIM.appex/Contents/MacOS/JapaneseIM)です。
logdはメッセージを受け取り、出力しています。
この場合メッセージにあるpid:491がエラーを出力、その出力を受けたlogdがメッセージを出力するという流れだと思います。(今回はpidがあったのでわかりましたが、必ずしもpidを一緒に出してくれる親切設計ではないと思います）
確かに、このログはMacを使っている最中に出力されています。触っていない時間帯ではこのログ出力はありませんでした。
JapaneseIMが原因だとして、どうして#DECODE failed to resolve UUIDが発生するの？はよくわかりません。ログメッセージを素直に受け取るとJapaneseIMがUUIDから何かの情報を取得する処理で、指定されたUUIDに該当するものが存在しない、これは通常ありえないパターンだ、だから警告の意味でログ出力しようってことですかね。
そもそも日本語入力処理で何をデコードする必要があるのか？辞書ですかね？よくわからないので放置しています。
出力されるタイミングは詳しく見ていてもよくわからないのですが、１秒の間に６０行ぐらい同じようなログが出力されます。しかも１回出力されたら終わりってわけではなく、２分後にまた６０行ぐらい出力されたりと本当に数多いです。ちなみに /var/log/system.logに占める#DECODE出力の割合は80％を超えることもあります 。
このログを抑止する１つの方法は、macOS Mojaveの標準日本語入力を使わない、Google日本語入力を使うことで回避できるかと思います。
もう一つは、ログを制御する方法です。今回はこちらのログを制御する方法で#DECODE failed to resolve UUID:・・を抑止しました。
【ログ制御で抑止する前に注意するポイント】
重要なポイント） 操作をミスる最悪のパターンは「macが使えなくなる可能性」があるところです。サポートできないので、この方法を試される方は自己責任でお願いします。
ポイント１） 管理者権限が必要です。
ポイント２） /etc/の設定ファイルを編集します。vi等の知識のない方はやめたほうがいいです。
ポイント３） この方法はJapaneseIMのログ全てを出力しなくする設定になります。
【#DECODE failed to resolve UUID:・・を抑止した方法】
/var/log/system.logへ出力しているのは/usr/libexec/logdです。このlogdはオンラインマニュアルがありません。macOS Mojaveではこれ以外にsyslogdというデーモンが存在します。どのような関係性なのか、なぜ２つもあるのかはよくわかりません。このような認識で試しているので不安だなぁと思う方は試さない方がいいです。
/etc/asl.conf設定ファイルを変更します。
オリジナルは以下のようになっています。
ミスに備えてオリジナルをコピーします。（バックアップです）
/etc/asl.confの修正にはviを使います。
/etc/asl.confの最後の行に以下を追加します。
これは、JapaneseIMからのログは無視するという設定です。
＝＞こちらのJapaneseIM指定は思い通りに消えないことがあることがわかりました。残念です。以下のPID指定は抑止できます。
PIDで指定したい場合は、以下のようにします。
PID方式にはデメリットがあります。macOSを再起動するとPIDが変わることがありえます。PIDが変わってしまった場合は、再度このファイルを修正し、設定を反映させる必要があります。
設定を元に戻したい場合は、先ほどバックアップしたオリジナルに戻します。
設定を反映させ#DECODEを出力させないようにします
以下コマンドで/etc/asl.confを再読み込みし、反映できます。
これで#DECODE failed to resolve UUID:ログはsystem.logに出力されなくなりました。
/var/log/system.logにたくさん出力される#DECODE failed to resolve UUID:を抑止する方法をご紹介してきました。管理者権限で設定ファイルの変更が必要です。そのため同じように困っている方全てにオススメするわけではありません。
macOS Mojaveで悩まされたこの現象は、macOS Mojave 10.14.6でも直りませんでした。
macOS Catalinaではこのようなログは今の所発生していません。
#DECODE failed to resolve UUID:はなんで出力されるの？
#DECODE failed to resolve UUIDを吐き出している大元は、JapaneseIMです。JapaneseIMはMojave標準の日本語入力機能を実現しているプログラムだと思います。PIDからJapaneseIMと推測できます。
ログ出力をよく見てみると２つのPID(プロセスID)があることに気がつきます。logd[ PID ] : #DECODE failed to resolve UUID: .... pid:491 ]（青い数字がPIDです）
はじめのPIDはlogd(/usr/libexec/logd)です。２つの目のPIDは、JapaneseIM(/System/Library/Input Methods/JapaneseIM.app/Contents/PlugIns/JapaneseIM.appex/Contents/MacOS/JapaneseIM)です。
logdはメッセージを受け取り、出力しています。
この場合メッセージにあるpid:491がエラーを出力、その出力を受けたlogdがメッセージを出力するという流れだと思います。(今回はpidがあったのでわかりましたが、必ずしもpidを一緒に出してくれる親切設計ではないと思います）
確かに、このログはMacを使っている最中に出力されています。触っていない時間帯ではこのログ出力はありませんでした。
JapaneseIMが原因だとして、どうして#DECODE failed to resolve UUIDが発生するの？はよくわかりません。ログメッセージを素直に受け取るとJapaneseIMがUUIDから何かの情報を取得する処理で、指定されたUUIDに該当するものが存在しない、これは通常ありえないパターンだ、だから警告の意味でログ出力しようってことですかね。
そもそも日本語入力処理で何をデコードする必要があるのか？辞書ですかね？よくわからないので放置しています。
#DECODE failed to resolve UUID:ログの嫌なところ
出力されるタイミングは詳しく見ていてもよくわからないのですが、１秒の間に６０行ぐらい同じようなログが出力されます。しかも１回出力されたら終わりってわけではなく、２分後にまた６０行ぐらい出力されたりと本当に数多いです。ちなみに /var/log/system.logに占める#DECODE出力の割合は80％を超えることもあります 。
#DECODE failed to resolve UUID:を抑止する方法
このログを抑止する１つの方法は、macOS Mojaveの標準日本語入力を使わない、Google日本語入力を使うことで回避できるかと思います。
もう一つは、ログを制御する方法です。今回はこちらのログを制御する方法で#DECODE failed to resolve UUID:・・を抑止しました。
【ログ制御で抑止する前に注意するポイント】
重要なポイント） 操作をミスる最悪のパターンは「macが使えなくなる可能性」があるところです。サポートできないので、この方法を試される方は自己責任でお願いします。
ポイント１） 管理者権限が必要です。
ポイント２） /etc/の設定ファイルを編集します。vi等の知識のない方はやめたほうがいいです。
ポイント３） この方法はJapaneseIMのログ全てを出力しなくする設定になります。
【#DECODE failed to resolve UUID:・・を抑止した方法】
/var/log/system.logへ出力しているのは/usr/libexec/logdです。このlogdはオンラインマニュアルがありません。macOS Mojaveではこれ以外にsyslogdというデーモンが存在します。どのような関係性なのか、なぜ２つもあるのかはよくわかりません。このような認識で試しているので不安だなぁと思う方は試さない方がいいです。
/etc/asl.conf設定ファイルを変更します。
オリジナルは以下のようになっています。
##
# configuration file for syslogd and aslmanager
##
# aslmanager logs
> /var/log/asl/Logs/aslmanager external style=lcl-b ttl=2
# authpriv messages are root/admin readable
? [= Facility authpriv] access 0 80
# remoteauth critical, alert, and emergency messages are root/admin readable
? [= Facility remoteauth] [<= Level critical] access 0 80
# broadcast emergency messages
? [= Level emergency] broadcast
# save kernel [PID 0] and launchd [PID 1] messages
? [<= PID 1] store
# ignore "internal" facility
? [= Facility internal] ignore
# save everything from emergency to notice
? [<= Level notice] store
# Rules for /var/log/system.log
> system.log mode=0640 format=bsd rotate=seq compress file_max=5M all_max=50M
? [= Sender kernel] file system.log
? [<= Level notice] file system.log
? [= Facility auth] [<= Level info] file system.log
? [= Facility authpriv] [<= Level info] file system.log
# Facility com.apple.alf.logging gets saved in appfirewall.log
? [= Facility com.apple.alf.logging] file appfirewall.log file_max=5M all_max=50M
ミスに備えてオリジナルをコピーします。（バックアップです）
cd /etc
sudo cp -p asl.conf asl.conf.orig
/etc/asl.confの修正にはviを使います。
sudo vi asl.conf
/etc/asl.confの最後の行に以下を追加します。
# add? [= Sender JapaneseIM] ignore
PIDで指定したい場合は、以下のようにします。
# add
? [= PID 491] ignore
PID方式にはデメリットがあります。macOSを再起動するとPIDが変わることがありえます。PIDが変わってしまった場合は、再度このファイルを修正し、設定を反映させる必要があります。
設定を元に戻したい場合は、先ほどバックアップしたオリジナルに戻します。
sudo cp -p asl.conf.orig asl.conf
設定を反映させ#DECODEを出力させないようにします
以下コマンドで/etc/asl.confを再読み込みし、反映できます。
sudo killall -HUP logd
これで#DECODE failed to resolve UUID:ログはsystem.logに出力されなくなりました。
まとめ
/var/log/system.logにたくさん出力される#DECODE failed to resolve UUID:を抑止する方法をご紹介してきました。管理者権限で設定ファイルの変更が必要です。そのため同じように困っている方全てにオススメするわけではありません。
macOS Mojaveで悩まされたこの現象は、macOS Mojave 10.14.6でも直りませんでした。
macOS Catalinaではこのようなログは今の所発生していません。
コメントシステムを利用したくない方は お問い合わせ からお願いします。
2013.8.19 DISQUS(外部コメントサービス)の利用を開始しました。
Facebook, google, Twitter等のアカウントで投稿可能です。