« Beaglebone Black Rev. C 調達 | トップページ | Beaglebone Black をバッテリー駆動 »

2014年10月29日 (水)

docomo L-07C の時限爆弾 (空き容量消滅!)

L-07C は 2011年夏モデルのスマートフォンだ。1年ほど前に中古を入手して使っていたのだが、半年くらい前から空き容量低下のメッセージが表示されるようになった。

Low_capa_warning

使用頻度の低いアプリをアンインストールしたりしてしのいできたのだが、ニッチもサッチも行かなくなったので詳しく調べてみた。なお記事の内容は root 化した V10d-20111221 ファームウエアに関するものである。

/*-----------  -----------*/

空き容量低下すると・・・

新たにアプリをインストールできなくなる。

Low_capa_install_error

それだけなら我慢すれば済むのかもしれないが、プリインストール分を含むインストール済のアプリに対するアップデートもインストールできなくなるので始末が悪い。

「空き容量低下」のメッセージをタップすると「アプリケーションの管理」の画面に飛ばされる。

Low_capa_app_list

これは「余計なアプリをインストールしてますよね」と言われているようなものだ。あまり使わないアプリをアンインストールしたり、可能なら SD カードに移動したりしてしのいできたが、こう言った対応は限界になってしまった。

ちなみにこの画面に表示される未使用が 150MB を切ると「空き領域低下」状態になるようである。

プリインストール・アプリを削除したら? との思いが頭をよぎったが、

Mount_mod

入っているフラッシュメモリーの区画が異なるので、削除したうえで区画を切りなおさないと効果が無いはずだ。これは大事だし一つ間違えば文鎮化のリスクもあるので、そこまでやる気にはならない。

 

本当の原因と対策

ここまで来るとさすがに気付いた。アンインストールや SD カードへの移動を繰り返しているのに空き容量が低下するのだからアプリが原因ではない可能性がある。誰かせっせと /data ディレクトリの下に空き容量を埋めるデータを作っている子が居るらしい。

du コマンドが使えないのが痛い(注参照)。使えるなら du -h -d 1 を何回か繰り返せば済むのだが、意を決して /data ディレクトリとその下のサブディレクトリを虱潰し ls -l することにした。と言ってもそんなにたいした数ではない。ほどなく /data/logger ディレクトリに動かぬ証拠が見つかった。

Huge_kernel_log

ログ置き場らしい。4MB 毎にローテートされているようだが、kernel.log はそうなっていないらしく飛び抜けて大きい。約 75MB ?、いや 1文字右にずれているから 約 750MB! コイツが空き容量を喰っていたのだ。

検索したら blog 記事「/data/logger/kernel.log が肥大化する (その2) (その3) (その4)」が見つかった。巨大化した kernel.log はさっくり削除しても大丈夫らしい。また標準の電話アプリで「3845#*07#」をダイヤルしてHidden Menu を呼び出し、下の方にある Log Service から入って Disabled にしてやればログを吐かなくなるらしい。

Log_service_at_hidden

これで新たなログは作られないはずだ。しかし気付かずに Enabled になってしまっても大丈夫なよう、誰がデータを作っていたのかもう少し調べてみた。 Android のベースの Linux を初期化している /init.rc の下の方にログサービスの定義らしきものがある。

Kernel_log_at_init_rc

/etc/save_kernel_log.sh がサービスの実体らしい。ちなみに kernel log 以外は logcat を使って 4MB 毎にローテートし、過去ログを 4 世代保存するようになっている。

Events_log_at_init_rc

上のスクリーンショットは event log に関するものだが他も同様である。これは /data/logger ディレクトリの状況と符合する。

/etc/save_kernel_log.sh の中身は予想通りだ。

Save_kernel_log_sh

コメントアウトしてある 1 行目が元々の内容で、これだとファームウエアをインストール以来のカーネルメッセージが延々と残る事になる。実際にその通りになったわけだ。

2 行目以降は私が追加した内容だ。真ん中のブロックは他のログに合わせて過去ログ 4 世代保存するようにローテートさせるロジックである。最後の行と組み合わせて使う。ただしローテートはファイルの大きさ基準ではなく再起動の都度になる。つまり合計で再起動 5 回分ログが残る。

これまでの実績を考えると 1 日あたり約 2MB ログが出ていたはずである。月一再起動を仮定すると 2 x 30 x 5 = 300MB ログが残る事になる。 Hidden Menu で Enabled になっているか、あるいは Disabled にしていてもログが止まらなかった場合の話である。これでは多過ぎると思うなら真ん中のブロックはコメントアウトしておいて、必要な時に編集して復活させればいいだろう。ただしその設定で再起動すると、再起動以前のログは無くなる。過去ログを 1 世代残す設定が妥当かもしれない。

最後の行はカーネルメッセージを現在のログに記録する設定である。

Hidden Menu の設定に関係なく全くログを吐かないようにするには元の内容をコメントアウトするだけでいい。必要な時に save_kernel_log.sh を編集する前提ならこれでいいはずだ。

実際に何回か再起動して確認したところ Hidden Menu の設定が Disabled でもログは完全には止まっていないのではないかと考えられる現象が見られた。ログはローテートされるので実用上あまり問題無いが、正確な状況と原因は良く分からない。どうなっているのだろう?

 

注: du コマンドについて

記事を書き終わる頃になって「busybox が使えたのでは?」と思い出した。間抜けな話だ。

Du_at_busybox

これなら一目瞭然。数字は kernel.log をスリム化した後のものである。この状態でも使用済 /data 区画はアプリとログがほとんどを占めている事が分かる。

分類 使用量 [MB] 該当サブディレクトリ
アプリ 306.5 app, dalvik-cache, data
ログ 70.5 logger
その他 3.0 上記以外

 

root 化しなくても可能な対処

これまで書いてきたことは root 化したファームウエアでないとできない。しかし大多数のユーザーは root 化なんて考えたことすらないはずだ。そんな非 root 化環境で kernel.log が成長してしまったらどうしたらいいのだろう。ファームウエアの再インストールしか手段が無い、と言うのは悲し過ぎるなぁ、と考えていると、kernel.log ファイルのパーミッション、と言うかファイルモードが -wr-wr-wr- (666) になっていることに気付いた。そう、誰でも書き込めるのである。

Nonroot_measures

これで良いはずだ。 kernel.log ファイルを上書きした後にカーネル・メッセージが出てログに出力されるとおかしなことになる可能性があるので reboot しておくのが無難である。

以上は L-07C 専用の手順である。他の機種で同じような問題が起こっている場合、ログのパスが分かれば同様に対処できる可能性がある。

他のログが -wr------- root:root なのに kernel.log だけこうなっているのは手動で巨大化したログに対処することが必要になると予め想定していたからかもしれない。そう考えると、他の機種でも同じような事が起こるなら、ドコモは全ての該当機種についてログのパスを把握して対処方法を予め準備していてもおかしくない。 USB デバッグを活かして USB ケーブルを繋ぎ何かスクリプトを実行する。この程度ならドコモショップの窓口でも実施可能だろう。そうそう、忘れずに USB デバッグの設定を元に戻すこと。そして Hidden Menu で Log Service を Disabled にするのも必要である(もしかするとスクリプトで実施可能なのかもしれない)。これは私にドコモのユーザーサポートに関する決定権があればそうしたかもしれない、と言う話であって、実際にどうなっているか全く不明である。もちろん最初から kernel.log をローテートする仕組みがあればこんなことは要らないし、その方が安上がりのはずだが、現実はそうなっていない。

 

今回のまとめ

少し古い Android スマートフォンに関して「空き容量が不足して・・・」と言う話をインターネット上でいくつか見かけた気がする。私は L-07C しか使ったことが無いので他の機種の事は分からないが、もし同じような事が原因なら実にバカバカしい話だ。

原因が分かってしまえば対処は簡単である。しかし root 化していないデバイスでユーザーが原因を突き止めるのは無理だろう。「このスマートフォンはストレージが小さ過ぎるから買い換えよう」と言うことになっている場合が多いような気がする。それが狙いだったらヒドイ話だ。

kernel.log スリム化後、今まで SD カードに移動したものを全て元に戻し、アンインストールしたアップデートの全てとアプリの一部を再インストールしても 890MB の空き容量が確保できた。

Capa_ok_app_list

空き容量低下メッセージが出るまで 700MB以上余裕がある。これなら常時 kernel.log を取得し、過去ログを 4 世代残すよう修正した save_kernel_log.sh で 300MB 使うことにしても大丈夫だ。 Log Service を全て Disabled にした上で /data/logger ディレクトリーを空にすれば、更に空き容量を 70MB 程度増やせるが、特に必要を感じないので未実施である。

|

« Beaglebone Black Rev. C 調達 | トップページ | Beaglebone Black をバッテリー駆動 »

携帯・デジカメ」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/543745/60562393

この記事へのトラックバック一覧です: docomo L-07C の時限爆弾 (空き容量消滅!):

« Beaglebone Black Rev. C 調達 | トップページ | Beaglebone Black をバッテリー駆動 »