OS X 10.9.4 Mavericksで時計がズレる; ntpdが正常に動作しない
めちゃくちゃ時計ズレるんですよね。
環境設定からntp使うチェックボックスをトグルすると時計合うんですが、めんどくさすぎる。
結論を一番最初に書きます。 私の環境では、pacemakerを無効化して、MacPortsからインストールしたntpdに入れ替えることで解決しました。
Apple純正ntpdのpoll間隔を変更して対処している方へ
64秒に1回のペースでntpサーバにアクセスしている可能性が高いです。サーバに無用な負荷をかけることになります。他の解決手段をおすすめします。
さて、詳細です。
時計ズレるとぼやいていたら、これを教えてもらいました。
OS X MavericksではNTPサーバーとの同期が出来ず、時間がずれる不具合がある?
まったく同期されなくなるらしいです。
たしかにntpqで見るとoffset 1200、jitter 400とかなってて明らかにおかしい。
jitterよりもoffsetのほうが大きい時点で何もかもがおかしい。
あ、ntpについてあまり知らなくて記事の意味がわからないようでしたらNTP設定 - とあるSIerの憂鬱 を読むといいと思います。
とりあえず一番お手軽そうな解決方法:/etc/ntp.confにminpoll 6 maxpoll 10
を設定する
OS X MavericksではNTPサーバーとの同期が出来ず、時間がずれる不具合がある?に書いてあったやつです。
とりあえず時計はズレなくなりました。
しかし、少ししてから気付きました。
時計が安定したらpoll間隔が2^10秒になるはずなのですが、2^6秒のまま。
64秒に1回アクセスしてたらさすがに迷惑ですよね。
そもそも、offsetとjitterがともに300くらいでまぁまぁおかしい。
このあたりでntpdまわりを入れ替えないと解決しないことに気付きました。
そこで、MacPortsからntpd入れてみました。
/usr/libexec/ntpd-wrapper
を編集してportsのntpdを起動するようにします。
exec /opt/local/bin/ntpd -p /var/run/ntpd.pid #exec /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift
portsのntpdはAppleのntpdと設定ファイルが違うので/etc/ntpd.conf
を編集します。
デフォルトだと、ntpd.conf
にはserver
行だけあってdriftfile
の記述はなく、restrict
の記述はntp-restrict.conf
にあります。
server ntp.nict.jp
server ntp.nict.jp
server ntp.nict.jp
server ntp1.jst.mfeed.ad.jp
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp
server s2csntp.miz.nao.ac.jp
driftfile /var/db/ntp.drift
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
動いてはいるようだがoffsetとjitterの数字が明らかにおかしい(300くらい)。
このあたりでもっと根本的な問題だと気付きました。
そこかしこにpacemakerが新しく入ったせいだと書いてあります。
ntp time drift mavericks | Apple Support Communities
を見るとpacemaker殺してMountain LionのntpdをTime Machineから発掘せよとか書いてあります。
pacemakerとはなんぞや。
pacemaker(8) Mac OS X Manual Page
"pacemaker adjusts the system clock periodically to compensate for clock drift. The clock drift is nor-mally normalmally computed by ntpd(8), which writes a clock drift value in /var/db/ntp.drift."
ntpdのドリフトに比べてなにが優れているのかまったくわからないわけです。
ドリフトというのは、ntpサーバと比べてるうちにシステムクロックのズレ方が分かるのであらかじめ自分で調整することなんですが(1日に3秒進むと分かっていれば3秒遅らせればいい)、もともとntpdについてる機能なのになぜ分けたのか……
仕方がないのでpacemaker
を殺します。
ntp time drift mavericks | Apple Support Communitiesによれば
/System/Library/LaunchDaemons/com.apple.pacemaker.plist
を削除すればOKです。
これで、portsのntpdがまともに動くようになりました。offset jitter ともに 10ms以下です。 スリープしてレジュームすると一時的にjitterが500msくらいになりますけど。
ちなみに、portsのntpqはntpq -4
してIPv4で使わないとなぜかconnection refusedになります。
ntp.conf
にいろいろな書き方でrestrict ::1
に類することを書いたのですが……
蛇足:
ところで、pacemakerを殺したらレジューム時に1分近く固まるのが治ったんですけど、なんなんですかね。
X.org上のChromeのマウスカーソルを指定する (追記あり)
追記
当該Issueに追加でコメントがありました. Issue 356228 - chromium - Chrome Aura will use Xorg cursor theme instead of DE cursor theme - An open-source project to help move the web forward. - Google Project Hosting https://code.google.com/p/chromium/issues/detail?id=356228
This really isn't a Chrome bug. You should be filing a bug report for your DE for not correctly setting the XCURSOR_THEME environment variable (and optionally XCURSOR_SIZE if you need a custom size) That's the standard way for every X application to know which cursor to use.
Chromeが悪いのかと思いきや,DEのせいだった,ということです.濡れ衣でした.すみません.
環境変数XCURSOR_THEMEと,必要ならXCURSOR_SIZEを適当な場所で設定しましょう.
--以下当初の記事--
X.org 上の Chrome で(Chromium もですが),マウスカーソルが DE で指定したものと違うものになります. この問題はバージョン35以上で発生します.
Issue 356228 - chromium - Chrome Aura will use Xorg cursor theme instead of DE cursor theme - An open-source project to help move the web forward. - Google Project Hosting https://code.google.com/p/chromium/issues/detail?id=356228
原因は,GTK+ でなく Aura を使うようになったことです.
Google To Replace GTK+ With Its Own Aura In Chrome - Slashdot http://beta.slashdot.org/story/19929
とりあえず X.org のカーソルを直接指定することで回避します.
Cursor Themes - ArchWiki https://wiki.archlinux.org/index.php/Cursor_Themes
を参照して作業しました.
場所はディストロによると思いますが,マウスカーソルのテーマが入っているディレクトリを探します.
Gentoo Linux では /usr/share/cursors/xorg-x11/ 以下でした.
使いたいカーソルの, index.theme が入っているディレクトリのシンボリックリンクを ~/.icons/default という名前で作ります.
Xを再起動すれば完了です.
Buffalo WZR-HP-AG300Hのtftpによる復旧
概要
Buffalo WZR-HP-AG300Hに間違えたdd-wrtのファームウェアを焼いて文鎮化しかけたので,その復旧方法をメモしておきます.
http://wiki.openwrt.org/toh/buffalo/wzr-hp-ag300h に書いてあるのと内容は基本的に同じだと思って下さい.
前置き
このルータは,LANポートの初期化後,数秒間だけ(4秒間?)tftpでのファームウェア書き換えを受け付けます. tftpでのファームウェア書き換えは以下の条件でのみ受け付けます.
- ルータのLANポートに,MACアドレス 02:aa:bb:cc:dd:20に向けて送信する.
- ルータのLANポートに,192.168.11.1に向けて送信する.
- 192.168.11.2からの送信.
- ファイル名にtftpを含む.
手順
今回はOS Xから行いました.
- ルータからすべてのLANケーブルを抜き,MacBook Pro(適当に読み替えてください)とLANケーブルでLAN 1ポートに直結します.MacBook Proに192.168.11.1/24を固定で割り当てます.
- OS X上で
$ sudo arp -s 192.168.11.1 02:aa:bb:cc:dd:20
と実行し,MACアドレスとIPアドレスを関連付けます(この表現が適切かどうかはわかりません).
$ netstat -r -n
を実行して
Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 192.168.11.1 2:aa:bb:cc:dd:20 UHLS 0 0 en0 192.168.11.2 127.0.0.1 UHS 1 0 lo0
となっていれば大丈夫です.
connect 192.168.11.1 binary rexmt 1 timeout 1 put tftp.bin
tftpをターミナルで起動します.ルータの電源を入れ,イーサネットがリンクしたタイミングで(Hardware Growlerを使用しているとわかりやすい),tftpに4. でコピーした内容をペーストして実行します.最後に改行を含むようにしていれば,ペーストしただけで実行されるはずです.タイミングがズレて失敗したら,成功するまで繰り返しペーストします.
転送に成功したら,ルータが再起動して起動完了するまで5分祈ります.
最後に
$ sudo arp -da
してルーティングテーブル(2. で設定した)を掃除します.
Buffalo WZR-HP-AG300H に dd-wrt を入れた話
概要
Buffalo WZR-HP-AG300H に dd-wrt を入れた話,なのだけれども,記事にするには基本的にあっさりいきすぎているし,そのわりには謎のバグも踏んでいる.そして,未だにそれの解決方法がわからないので,記事にするのはそれを解決してからと思っていたが,2週間以上経ってしまったので,いい加減にとりあえず書いておこうかと思ったわけである.
dd-wrt化してよかったこと
事前に分かっていたこと
出力を自由自在に絞れること以外は,Buffalo の純正ファームだって dd-wrt ベースなので,そこまで期待していなかった.なんか違法に高出力にできるらしいけれども,別に一人暮らしで高出力にしても何も使いどころがないし,なにより違法である.違法に高出力なルータって響きだけはいいですね.
実際に使って分かったこと
純正ファームでは見られないレベルでステータスやログが見られる.Load Average,空きメモリ,コネクション数,Wi-Fiのクライアント毎のリンク速度とシグナルとノイズの強さにSN比,あと転送量のグラフとかがWebから確認できる.syslogとかは純正ファームにもあるはず.
dd-wrt化して微妙だと思ったこと
起動がめちゃくちゃ遅い.3分とか平気でかかる.最後のPPPoEコネクション張るまでが長い.起動し終わったと思っても繋がっていない. 無線まわりを中心に,設定を変更すると応答しなくなる,電源断からの再起動を2回しないと正常起動しない.設定は変更されるけれども.これがはじめに書いた謎のバグ.つまり,設定変更に3分*2くらいかかる.
まぁ,起動してしまえば軽快そのものである.
実際にやったこと
買うルータを選ぶ
Router Database | www.dd-wrt.com で対応機種を見て,Table of Hardware - OpenWrt Wikiなどの wiki でハードウェアスペックとか見て悩む.
とりあえず5GHz帯があることを条件にしていた.メモリの容量が多いといろいろと楽らしい.
どのバージョンを入れるか悩む
最新版はこわい(個人的に).Timeline – DD-WRT でチケットを追って,どの辺りのバージョンを入れれば安泰っぽいか考える.DD-WRT v24-sp2 (02/11/13) std - build 20675 にした.コアライブラリのバージョンアップの直前なので.
ダウンロードして焼く
(ftp://ftp.dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2013/02-11-2013-r20675/buffalo_wzr-hp-ag300h/) から (ftp://ftp.dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2013/02-11-2013-r20675/buffalo_wzr-hp-ag300h/buffalo_to_ddwrt_webflash-MULTI.bin) をダウンロードして,普通に公式ファームウェアの設定画面から焼く. どうしてこんな簡単に焼けるのかについては謎だけれども Buffalo がわざわざアホなことをしてくれている.
普通に設定する
もう焼いてしまえば純正ファームと変わらない.ただ機能が少し多くて不安定なだけである. わからない設定項目は dd-wrtのwiki などを見ながらさっさと設定をする.ここで何回も応答しなくなって面倒ではあったが不安定なだけである.
疑問が残っている場所
Antenna Gain
調べると,ハードウェアに付いてるアンテナの特性の数字を入力するものらしい.3dBiと入力するのが正しいはずだが, 0dBiじゃないとリンクが非常に不安定になる.謎い.
設定すると応答しなくなる
もしかしてWebからじゃなくてsshとかtelnetとか使って設定すれば回避できるのかもしれない,とか思っているうちに設定が終わってしまった.
感想
基礎知識があれば失敗のしようがないと思いました.
ググると出てくるブログが,違法な高出力に惹かれて,ネットワークの基礎知識もないのにいじくり回してるようなものが多くて,ああ,検索ノイズだなぁ,と思いました.
中身はLinuxですし.たいしたことないです.
今後のなんちゃら
せっかくUSBポートついてるので,sshfs入れてNASにでもしてみますかね.あまり性能的に余裕がなさそうですけれども.
Linux 3.7.x で MagicTrackpad の2本指操作がうまくいかない
https://bugzilla.redhat.com/show_bug.cgi?id=908604
なんだか無駄に xev とか dmesg とか確認したけれども,結局は上記リンク先に書かれているようなことらしい.
hid-magicmouse が更新されなさすぎて,kernel の更新に追い付いてなかったってことでいいのだろうか,まったく自信はないが,そのように見える.
$ git clone https://github.com/bentiss/hid-magicmouse.git
$ cd hid-magicmouse
$ make
$ sudo make test
したあとに
$ sudo make install
すれば対処完了なのだが,initrd を使っていない自分の環境では最後にエラーが出るので,install.sh
の37行目以降をコメントアウトして使った.もっとも,エラーが出ても既にインストールは完了しているのだが.
これで無事 MagicTrackpad は Linux Kernel 3.7.10 上で正常に動作している.
機能のgst-plugins-ffmpegの話の続き; FirefoxとChromiumは同時にインストールできるようになる?
昨日,あれを書いたあと,なんとなく検索したらこんなものが出てきたのだが ―― Bug 806917 - support GStreamer 1.0 ―― FirefoxがGStreamerに移行すると,FirefoxのHTML5の実装がlibav依存になることになる.Chromiumが相変わらずffmpegをHTML5のために使っていくのだとしたら,ffmpegとlibavをシステム内で共存させる方法がない現状だと,片方のブラウザしか使えないことになる.
そもそもffmpegとlibavがなぜfolkして別れたのかイマイチ正確なことはわからないのだが,本の虫: ffmpegとlibavの背景事情を読んだらなんとなく事情は分かったような気になった.
と,ここで重大な勘違いに気付いた. そもそもGStreamer 1.0のlibavプラグインはffmpegでもlibavでも動くらしい.なーんだ問題ないじゃないか. firefoxがGStreamer 1.0に対応したら,chromiumと共存可能になるわけだ.やれやれ. 古い方のGStreamerのffmpegプラグインが更新されるのは少し考えづらいし,期待するならそっちかな.
ただ,Chromiumを使いたいならlibavが使えないことには変わりがなくて,GStreamerとしてはlibav推奨,つまりFirefoxは間接的な形でlibavを使ったほうがよさそう,つまり,どちらのブラウザを好むかでライブラリを選ばされそうなことには変わりがないように見えるけれども.
media-plugins/gst-plugins-ffmpeg-0.10.13-r2 のコンパイルがコケる
起きたこと
うちのGentoo Linux default/linux/amd64/13.0/desktop/gnome でmedia-plugins/gst-plugins-ffmpeg-0.10.13-r2 のコンパイルがコケた.
原因
media-video/ffmpeg-1.0.6 が入っていた.
そもそもなんでそんな新しいffmpegを入れたのかというと,=<www-clients/chromium-27 が要求してきたため.
そもそも gst-plugins-* って
gst-plugins-* は gst-plugins-*:0.10 と gst-plugins-*:1.0 がある.
gst-plugins-base とか gst-plugins-meta とかを入れるとUSEフラグで依存関係でいい感じにプラグインが引っ張られてemergeされる.
gst-plugins-meta に ffmpeg フラグがつくと gst-plugins-ffmpeg か gst-plugins-libav が入る.
1.0のほうはlibav一本に,gst-plugins-libavに移行している.
gst-plugins-ffmpeg:1.0はない.
libav ってなに
ffmpeg がなんかforkしたらしい……
ファイル名が同じだったりして共存できないくせにABIやらAPIやら違うらしい.そもそもffmpegとかlibav自体もバージョンが違うとこういうことが起こる,というか今回起きたからgst-plugins-ffmpegがコンパイル通らなくなった.
gst-plugins-ffmpegはlibavでも動くようだが,0.8.2なんて古いバージョンでしか使えないようなので,今とインタフェースが違うのだろう.
現状
gst-plugins-ffmpeg に依存してらっしゃる方は
firefox
gnome-2.32.1-r2