/data/logger/kernel.log が肥大化する (その4)

何が原因で build.prop が書き換わったのかが見えてきました。2ch の

--- docomo Optimus bright L-07C Part8 112 名前： SIM無しさん [sage] 投稿日： 2012/06/09(土) 13:18:44.93 ID:SbwIU394 >>103 >>104 がヒントになり、build.prop をチェック。 persist.service.kernel.enable=1 を 1 → 0 に書き換えてログ出力抑制ができました。なぜ変わっていたかは 不明。自分で書き換えた記憶が無いんだが... 前スレ >>911 と >>960 の方、まだ見ていたら一度チェックしてみてください。   113 名前： SIM無しさん [sage] 投稿日： 2012/06/09(土) 13:41:38.63 ID:MbhAmjmm >>112 root取ってbuild.propを編集してもいいんだけど、裏メニューに入って Log Serviceでdisableにすればいいのでは？   114 名前： SIM無しさん [sage] 投稿日： 2012/06/09(土) 13:48:29.37 ID:MbhAmjmm あと /data/property/persist.service.karnel.enable に属性が保存されているっぽい。 出先で下手にいじって文鎮化させたくないので確認してませんけどｗ

113 が原因だったみたい。

GPSの精度上げとかで裏メニューに入っていじっていたのが原因。知らないうちにログ取る設定にしてしまった模様。

Optimus Bright君のバッテリ持ち

デカバッテリ装着後も、さらなるバッテリ持続の道を探るべくチャレンジ中。とはいえ Gigazine の記事 を読むと、自分の努力だけでは溝は埋まらない気もする。

次の例だと、減りが非常になだらか。CPU Spy で見てみると、Deep Sleep の時間がほとんどを占めているのがわかる。

反対に、次の例だと最低クロックの 300MHz で動き続けている何かがいる。そのため、減りも非常に右肩下がり。
ここのところ、PSPでゲームをしている関係で、L-07C で動画を見たりはしていない。Yahoo! Headline をチョロチョロッと見たり、PC Watch や AKIBA PC Hotline! や Dolphin でブラウジング等々。あえて終了まで持って行かず、裏タスクにして試してみました。

アンドロイドアプリを使っていて思うのが、終了機能が無いものがほとんど。戻る連発で終了するのかもしれないけど。常駐ものも多い。自分で常駐させるか否か選択させてくれてもいいんジャマイカ。OSがメモリの管理をするのが売りらしいが、逆にバッテリの持ちとか悪くさせている気がします。

オイラの場合、root化かつプリインストールソフトはtitanium backup pro で凍結しているからいくらかましだけど、普通に使っている人はけっこうメモリに余裕が無いんじゃないかなぁ。

LED電球を買ってみた

省エネに協力というわけでも無いのだが、風呂場の電球が切れたのでLED電球に交換をしてみた。ピンからキリまで色々あるが、入門(?)ということであきばおーで\600で売っているオーム電機製を購入。昼光色と電球色があるんだが、嫁の指示で電球色を購入。明るさだけだったら昼光色に軍配が上がるんだが。

ご使用上の注意を見ると色々と気になる点が... 買った後に気づいても意味ないんだけど (^-^*)

• 風呂場だけに天井付近の温度は40℃近くまでいくかも?
• 風呂場だけに結露するかも?  パッキン付きの電球カバーで白熱球は平気だったけど。

 ふと思ったんだけど、今ある電球の代わり(というか入れ換え)にするとなると、意外にLED電球の条件を満たしていないんじゃ無いかな。
うちの例だけど、天井の照明を変えることになるんだが、天井側には反射板があり微熱とはいえLED電球の熱もこもりそう。寿命を縮めることにならないかな?

今回は風呂場の電球の交換、一日3時間使うとして一年で1,095時間。カタログスペックの4万時間を全うすると約40年。死ぬまで変えることもなさそうです orz

とはいえ、カタログスペック通りの環境では無いので、どれくらい持つか楽しみに取り付け日の記録を残すことにします。

ESXiでゲストOSを自動起動させる

勉強用のESXiだが、必要時に電源オン→手動でゲストOSの起動を行っている。実際のところ、最終的には全ゲストOSを起動させることになるので、電源オフで自動シャットダウン・電源オンで自動起動するように設定を変更した。参考にしたのはここのページです。

いや、便利ですな。もっと早く設定をしておけば良かった。

/data/logger/kernel.log が肥大化する (その3)

やっと原因が判明しました。/system/build.propの

persist.service.kernel.enable=1

が原因でした。早速 0 に書き換えて再起動。予想通り /data/logger/kernel.log にログを吐き出さなくなりました。これで一安心。他のログも見ることっもおそらく無いと思うんで

persist.service.main.enable=0
persist.service.system.enable=0
persist.service.radio.enable=0
persist.service.events.enable=0

に変更して、ログ出力抑制をすることにしました。自分で書き換えた記憶は無いんだが、なんで変わっているのかって疑問は残ったままですが。
面白そうな設定もできそうなので、build.prop をいじって遊べそうです。

追記：23:05
念のため、家に帰ってもう一度チェック。ok、肥大化無し(というよりは出力無し)です。一件落着。

/data/logger/kernel.log が肥大化する (その2)

色々調べたけれども原因が掴めず。10c までダウングレードして 10d に上げることにしました。

で、10c を入れて root化した後に init.rc を見たのですが loglevel は 7 でした。その後 10d に上げ、kernel.log の増え方をチェックしましたが、異常な速度で肥大化することはないです。個人的には 3 位で十分だと思うんですが。7 が基本なんですかね?
あと、init.rc は編集しても起動時に初期化されちゃうのが正しい仕様なんですかね?

原因は分かんないですけど、とりあえず kernel.log が内部ストレージを食いつぶすことが無くなったので良とする。再発したらどうするかなぁ。 main.log、events.log、radio.log、system.log は loglotate しているのに、どうして kernel.log は貯まりっ放しなんだろう?

ストレージの容量が減ったら、kernel.log と当たりを付けて削除することを忘れないようにしなければ。

23:20 追記
と、思ったのも束の間。家に帰ってチェックしたら、14M に増えている。12時間で 14M ってことは、一日だと 28M になってしまう。20～30日に一度削除しないとダメだ...  WindowsUpdate のタイミングで月例行事にする?

# なんとか解決の方法を考えないと... トホホ

/data/logger/kernel.log が肥大化する

2012年5月27日に 10d を root化した後の現象。/data/logger/kernel.log がとんでもないスピードで肥大化している。

調べた結果、/init.rc の loglevel が 7 になっているためと分かる。
だったら 7 → 3 へ変更すれば問題ないと思ったのだが、これが一筋縄ではいかぬ。init.rc を PC へコピー → 編集後 L-07C へコピー → パーミッションとかオーナーを変え一件落着かと思ったのだが、再起動をするとなぜが 7 に戻っていた... orz

犯人は誰?  今のところ見つかっていない。初期化して、再度試すって手もあるができれば避けたい。なんとか犯人を捜さなければ...

# 誰か知っていたらアドバイスをお願いします