Ubuntu 13.04における幾つかのメモ(Google Chromeとcpufreqd関係・2013/4/27時点)
Google Chromeが動かない件とその対処
2013/4/27時点でダウンロード可能なGoogle Chromeはlibudevのバージョン0(libudev0)に依存しているが、Ubuntu 13.04ではlibudevはバージョン1(libudev1)しかなく、動かすことができない。$ objdump -p /opt/google/chrome/chrome | grep libudev NEEDED libudev.so.0
しかし、Ubuntu 12.10のlibudev0をインストールして使うことはできる。例えば
packages.ubuntu.com/quantal/libudev0
からアーキテクチャ名のリンクをたどって.debファイルをダウンロードしてインストールする。
すると、そのlibudev0を用いてGoogle Chromeは正常に起動するようになる。
$ ldd /opt/google/chrome/chrome | grep libudev
libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x00007f0c7ef7d000)cpufreqdがシステムのデーモンとして起動しない件とその対処
Ubuntu 13.04でcpufreqdをインストールすると、インストール最後のデーモン自動開始の段階で「buffer overflow detected」の表示とともに落ちる。つまり、システムのデーモンとしてうまく起動してくれない。しかし、コマンドで直接試しに起動してみるとうまく動作し
(テスト開始) $ sudo cpufreqd -D -V 7 (Ctrl+Cでテスト終了)
デーモンとしても
(デーモン開始) $ sudo cpufreqd (デーモン停止) $ sudo killall -INT cpufreqd
うまく動作していることが分かった。
しかし、何故か-fオプションで設定ファイルを指定すると落ちるようだ。
$ sudo cpufreqd -D -V 7 -f /etc/cpufreqd.conf *** buffer overflow detected ***: cpufreqd terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f7f340405cc] /lib/x86_64-linux-gnu/libc.so.6(+0x110560)[0x7f7f3403f560] /lib/x86_64-linux-gnu/libc.so.6(+0x110b04)[0x7f7f3403fb04] cpufreqd(main+0x308)[0x402bb8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f7f33f50ea5] cpufreqd[0x403c9d] ======= Memory map: ======== (以下略)
/etc/cpufreqd.confは既定の設定ファイルで-fオプションを指定しなくても使われるため、今回は/etc/init.d/cpufreqd内の-fオプションで設定ファイルを指定している部分を削って対処することにした(もちろん、根本的な解決ではないが)。
--- /etc/init.d/cpufreqd.orig +++ /etc/init.d/cpufreqd @@ -81,7 +81,7 @@ load_cpu_module load_governor_modules if check_for_cpufreq_support ; then - start_daemon $DAEMON -f $CPUFREQD_CONFFILE + start_daemon $DAEMON else # log_failure_msg " Errors occurred starting cpufreqd" retval=1 @@ -106,7 +106,7 @@ killproc $DAEMON sleep 1 if check_for_cpufreq_support ; then - start_daemon $DAEMON -f $CPUFREQD_CONFFILE + start_daemon $DAEMON else # log_failure_msg " Errors occurred starting cpufreqd" retval=1
これで一応/etc/cpufreqd.confを用いたデーモンの起動が可能になる。デーモンは(既定の設定では)OS起動時に自動で起動するが、手動で操作すると下のように正常に処理されることが分かる。
(システムのデーモンを開始) $ sudo service cpufreqd start * Starting CPU Frequency daemon cpufreqd ...done. (システムのデーモンを再起動) $ sudo service cpufreqd restart * Restarting CPU Frequency daemon cpufreqd ...done.
(2013/5/28)この件についてはバグ報告ページの9番のコメントの人が問題点の詳細についてを解説している(ビルドされたタイミングとその時のCライブラリのバージョンが関係している模様)。解決策としては(realpath()関数の正しい使い方として)cpufreqdのソースの中でパス名の長さの上限値を「512」と決めてしまっているのをシステムのCライブラリのlimits.hが存在する場合にこれを参照して「PATH_MAX」を用いるようにすれば良く、公式版の最新の状態(Gitを用いた開発版)では2010年に修正が適用されているが、バージョンの付いたリリースにはなっていない(バージョン部分を「2.4.3」としている修正もあるがサイトでは公開されていない)ため、Ubuntuとしては、他の数箇所の更新を含んだ最新の状態(バージョン2.4.3相当)にパッケージを更新するか、あるいはバージョン2.4.2に該当部分の修正のみが取り込まれるかのどちらかになりそう。いずれにしても、この問題は根本的な解決に向けて大きく進んだ感じがする。
(2014/2/7)該当部分の修正(パス名の長さの上限値であるPATH_MAXについて、limits.hが利用可能な場合にこれを参照する)が適用されたバージョン「2.4.2-2ubuntu0.1」がアップデートにより提供され、この問題はようやく解決した。
使用したバージョン:
- Google Chrome 26.0.1410.63
- cpufreqd 2.4.2
