症状：

iPhone 3GSをiOS4にアップデートして以来、バッテリーの減りが異常に早くなった。

原因：

（多分）スリープ中もWi-Fiが有効になる状態だったから。

解決策：

（私の場合）スリープボタン+ホームボタン長押しで強制リセットしたら直った。

去年12月に買ったiPhone 3GS。以前は2日充電しなくても余裕があったのに、iOS4にアップデートして以来、1日放置しておくだけで残り15%近くまでバッテリーを消耗する状態になった。「iOS4 バッテリー」というキーワードで検索してみると、同様の症状を訴える人はたくさんいる。中でも『iOS4ではスリープ中でもWi-Fiがオフにならず、そのせいでバッテリーを早く消耗する』という情報が気になった。言われてみれば、iOS4にして以来、スリープから復帰させる時にWi-Fiのシグナルがいつも立っている。以前なら0.5秒〜1秒くらいの間があって「3G」→「Wi-Fiシグナル」と表示が切り替わっていたのに。

しかし特に問題がない人も多いところを見ると、これがiOS4の正規の挙動なのかどうかは怪しい。とりあえずものは試しと、買ってから初めて強制リセットを試してみた。方法は右上のスリープ/スリープ解除ボタンとホームボタンを押し続け、「電源オフ」のスライダが出ても押し続け、画面が暗転して銀色のリンゴが出てくるまで待つ。…すると何かの設定がリセットされたのか、Wi-Fiの挙動が以前の状態に戻り、バッテリーの異常な消耗も解消された。

必ずこの方法で復旧するとは言い切れないが、同様の問題で悩んでいる方は一度試してみると良いかと。

DB内のMEMORYテーブルのサイズを、テーブルごとにグラフ化するための munin プラグインを作ってみました。

mysql_memory_tables_

インストール

munin-node 本体のプラグインディレクトリ（/usr/share/munin/plugins など）にコピーしてください。

設定

ワイルドカードプラグインなので、mysql_memory_tables_{チェック対象となるDB名} という名前でシンボリックリンクを張ってください。

ln -s /usr/share/munin/plugins/mysql_memory_tables_ /etc/munin/plugins/mysql_memory_tables_db1

データを取得するには対象DBの INFORMATION_SCHEMA にアクセスする権限が必要です。プラグイン設定ファイル（/etc/munin/plugin-conf.d/munin-node など）で mysql コマンドに渡すユーザ名・パスワードを指定してください。

[mysql_memory_tables_*]
env.mysqlopts -u cicindela --password=hogehoge

動作確認

munin-run コマンドでテストができます。

# 値の表示
munin-run mysql_memory_tables_db1
 
# グラフ設定情報の表示
munin-run mysql_memory_tables_db1 config

動作が確認できたら munin-node を再起動してください。

Software RAID1を組んでいるサーバで、CentOS 5.3 -> 5.4にアップグレードしたところ、週末ごとに次のような警告メールが届くようになった。

/etc/cron.weekly/99-raid-check:

WARNING: mismatch_cnt is not 0 on /dev/md0

/proc/mdstat 等には特に異常などは見当たらないし、構成の異なる複数のサーバで同じ現象が起こったので、ハード的な問題ではないだろうと判断し、忙しかったこともあってそのままにしていた。しかしやはり気持ち悪いので、きちんと調べてみた。

メール中にある通り、この警告は /etc/cron.weekly/99-raid-check というスクリプトから送信されている。このスクリプトを提供しているのは mdadm パッケージで、5.4で更新されている。更新内容はレッドハットのサイトで RHBA-2009:1382-1 として提供されており、99-raid-check について説明しているのは、次の2箇所である。

* LinuxのソフトウェアRAIDスタックでは、データスクラビングがサポートされています（RAIDアレイのディスクを読み取って不良セクタを検索し、不良セクタが見つかると、他のディスクやパリティの情報を使用して、不良セクタを正常なデータで書き直します）。しかし、mdadmパッケージはこの機能を利用していませんでした。今回のパッケージは、cronジョブが/etc/cron.weeklyに追加されており、ディスクをチェックして不良セクタがないかどうかを確認し、見つかった場合は修復します。（BZ#233972）

* 今回のアップデートでは、mdadmに冗長アレイでの「データスクラビング」を可能にする新しい機能が追加されています。データスクラビングでは、冗長アレイ内のドライブ上で不良セクタが検索され、見つかった場合は他のドライブのデータを使用して修正されます。それによって、読み取りエラーを返すセクタは再構築されます。注：この新しいパッケージでは、データスクラビングはデフォルトでオンになっています。この機能は週1回実行され、実行中にある程度のパフォーマンス低下を引き起こす場合があります。パフォーマンス上の理由でこの機能を無効にしたい場合、アレイに対して実行されるチェックのタイプを管理したい場合、あるいは、どのアレイをチェックするかを制御したい場合は、/etc/sysconfig/raid-checkファイルを編集します。オプションを設定する方法の詳細は、そのファイルにコメントとして含まれています。（BZ#513200）

「データスクライピング（Data Scrubbing）」とは何か、なぜ重要なのかについては、ここで示されているBugzilla #233972およびその先のリンクに説明がある（一箇所リンクが切れているのはRAID/Software – GEntoo Linux Wikiだと思われる）。

データスクライピングを実行するには、root権限で次のコマンドを実行する。これによって不良セクタが検出され、自動的に修復される。99-raid-check が実行するのも、まさにこのコマンドである（少なくともデフォルトの設定においては）。

echo check > /sys/block/mdX/md/sync_action

ではこのコマンドと、問題の mismatch_cnt とはどう関係するのか。/etc/sysconfig/raid-check のコメントを読むと次のように書いてある。

If it finds good sectors that contain bad data (meaning that the data in a sector does not agree with what the data from another disk indicates the data should be, for example the parity block + the other data blocks would cause us to think that this data block is incorrect), then it does nothing but increments the counter in the file /sys/block/$dev/md/mismatch_count.

つまりセクタ自体は正常だが、中に入ってるデータがディスク間で異なる場合に mismatch_cnt が増加するということらしい。

ならば mismatch_cnt が 0 でないということは、ただちにRAIDが正常に機能していないことを意味するのだろうか？いろいろなMLの投稿などを読む限り、少なくとも swap パーティションを含むRAIDデバイスにおいては、全く正常であっても各ディスク間の内容が異なり得る…すなわち mismatch_cnt が0でないことがあり得るようだ。では swap を含まないパーティションの場合は？私の（また他のCentOS利用者の）ように、/boot のみを含む md0 の場合は？……これがよく分からない。この投稿を読む限り、ある種の状況においてはそうしたことも起こり得る、とのことである。

もしそうした状況に該当するなら。mismatch_cnt が 0 でなくとも、異なっているのは実際にはファイルシステムからアクセス不能な部分であって、システムの運用には影響しないのであれば。修復する方法はある。check の代わりに repair を使うことである。

#このコマンドを実行する前に以下の説明をよく読んでください！！
echo repair > /sys/block/mdX/md/sync_action

ただし /etc/sysconfig/raid-check には、次のような恐ろしいコメントが書いてある（強調は私による）。

The repair option does the same thing, but when it encounters a mismatch in the data, it automatically updates the data to be consistent. However, since we really don’t know whether it’s the parity or the data block that’s correct (or which data block in the case of raid1), it’s luck of the draw whether or not the user gets the right data instead of the bad data.

というわけで、以下は「それでも自己責任でこの方法に賭けるぜ！」という方のみ読んでください。

まず各デバイスの mismatch_cnt の値をチェックしておく。

cat /sys/block/md0/md/mismatch_cnt

そして repair を実行する。

sudo sh -c 'echo repair > /sys/block/md0/md/sync_action'

進行状況は /proc/mdstat で確認できる。

cat /proc/mdstat

repair を実行しただけでは mismatch_cnt は更新されないので、もう一度 check を実行する。進行状況はやはり /proc/mdstat で確認できる。

sudo sh -c 'echo check > /sys/block/md0/md/sync_action'

終了したら mismatch_cnt をチェックして、0 になっているか確認する。

cat /sys/block/md0/md/mismatch_cnt

……

参考にしたサイトははてブの mismatch_cnt タグにまとめてあるので、この記事に書いてあることを鵜呑みにせず、自分で調べ自分で判断するようお願いします。

16GBモデルで15000円弱。同容量のiPod nanoより2000円ほど安い。その安さに惹かれて購入したのだが、良い意味で驚かされた。それまで使っていた二世代前のiPodに比べて、圧倒的に音が良い。同じイヤホン（MDR-EX90SL）、同じ音源（mp3やAAC）なのに、全く違って聞こえる。さすがに最近のiPodならもう少し差は縮まるのかも知れないが、個人的にはもうiPodに戻ろうとは思わない。

私は初代からのiPodユーザなので、iPodシリーズとはかれこれ8年近い付き合いになる。その間にも、実はiPodの音を疑ったことは何度かあった。曲によってはっきりと不快に感じることすらあった。その度にイヤホンが悪いのか音源が悪いのかと疑い、iPod本体に目を向けることはなかった。iPodに代わる選択肢は事実上存在しない状況だったので、iPodを疑っても仕方がなかったのだ。でもついにはっきりと現実を認識する時が来てしまった。高音の歪みが不快で仕方なかったあの曲を、NW-S645は見事に奏でてくれた。iPodは、音が悪かったのだ……。

回顧はこのくらいにして、少し真面目なレビューを。

曲の転送

NW-S645は「ドラッグ＆ドロップ転送」に対応しているので、サポート対象外だがWindows以外でも使える。私の母艦であるMacBook Proに接続すると普通のUSBストレージとして認識された。ボリューム名は「WALKMAN」。中に MUSIC というディレクトリあるので、そこにコピーすればあとは勝手にアーティスト名やアルバム名のデータベースを構築してくれる（コピーしたディレクトリ単位で再生することもできる）。またiTunes Storeから購入した曲（PlusなどDRMがかかっていないもの）を転送すると、アートワークも正常に反映された。しかしiTunes上で後から割り当てたものについては反映されないようだ。

これは私の環境だけかも知れないが、取り外す際にちょっとしたトラブルがあった。Finderの取り外しアイコンをクリックすると一旦は接続解除されるのだが、すぐにまた接続が開始されてしまうのだ。結局「解除した瞬間にUSBケーブルを引っこ抜く」という、なんともいい加減な方法で対処することにした。

操作性

操作性はすこぶる良い。ほとんど何の不満も無い。iPodより使いやすいと思う。というか、これも比較して初めてはっきり認識できたことだが、iPodのタッチホイールによるUIは、別に使いやすくはなかった。例えば曲の再生方法（リピートやシャッフル）を変更したいとき、iPodだといちいちトップメニューまで戻って「設定」から変更する必要があったが、NW-S645は「OPTION」ボタンから即座に変更できる。曲を選ぶ時のカーソルの移動速度はホイールにはかなわないが、左右ボタンでA-Zあ-わ移動ができるので問題ない。全体として、よく考えられた作りになっていると思う。

その他

本体デザインは金属やガラスの質感が美しく、iPod nanoほどエレガントではないものの、とてもカッコいい。液晶も綺麗で見やすい。ACアダプタが別売りなことには面食らったが、そもそもバッテリの持ちが非常に良いのであまり問題にならない（実はiPodのものが流用できそう？）。

追記：音質について

ピアノやヴァイオリンなどの比較的静かな曲だとそのままでも素晴らしい音が出るのだが、JPOPなどの賑やかな曲だとボーカルが埋没してしまって、ひどくアンバランスに聞こえることがある。そういうときはイコライザを「ポップス」あたりに変更してやれば、見違えるような（聞き違えるような？）音になる。イコライザもOPTIONボタンから簡単に切り替えられるので、いろいろ試してみると面白い。

XREAが重過ぎて使い物にならなくなったので、エックスサーバーに移転した。ここを選んだ理由は

• PHP5, MySQL5が使える
• 比較的値段が安い（X10プランで月額1050〜1260円）
• ネット上の口コミでは速度に対する評価が高い
• “ハズレ”を引いたときの救済措置簡単サーバ移動機能がある
• SSHが使えないので、派手なことをするヤツは少ないだろうという希望的観測

今のところ速度には満足。サーバの管理画面も使いやすい（若干パワーユーザ向けだが）。WordPressも問題なく移転できた。

WordPressの移転にはいろいろな方法があるようなので、私の方法も紹介しておく。最も原始的かつ確実な方法で行った。

エックスサーバーでの下準備

1. 管理画面「MySQL設定」で新しいMySQLデータベースとMySQLユーザを作る
2. 「ドメイン設定」で独自ドメインを登録する
3. できればここで /etc/hosts ファイルを書き換えてきちんとアクセスできることを確認しておく。WebサーバのIPアドレスは「DNSレコード設定」で確認できる

旧データのバックアップと修正

1. XREAの管理画面「データベース」で「保存」ボタンを押してバックアップを作成する
2. 作成されたmysql.dumpおよびサイトの全ファイルをローカルにコピーする
3. wp-config.php を開き、データベース設定をエックスサーバーのものに書き換える

エックスサーバーにアップロード

1. 管理画面からphpMyAdminにログインして、mysql.dumpを実行
2. ドキュメントルートに全ファイルをコピー
3. 例によって /etc/hosts を書き換え、WordPressが正常に動くことを確認

あとはDNSを変更すればOK。

http://twitter.com/serpere

「フォローしないと面白くない」とは聞いていたので、とりあえず登録時におすすめされた有名人アカウントを半分くらい、それから購読しているブログの中でアカウントがすぐ判明した何人かをフォローして開始。

当たり前だが、まださっぱり面白さが分からない。混雑したファミレスの中で、他テーブルの雑談を聞くともなしに聞きながら独り言をつぶやいているような、ものすごい違和感。でもそういう雑談に思わず心の中で突っ込みを入れてしまうことがあるように、@xxx で突っ込みを入れていけば面白くなってくる…のだろうか？

会話のための会話を楽しめる人向けというか、ある意味では最も純粋なコミュニケーション・ツールという気もする。当面はひたすらフォローする人を増やしながら様子を見ていこう。

もんじゅMCスクエア

久しぶりに良く晴れた夏の休日、敦賀半島の突端にある高速増殖炉「もんじゅ」に行ってきた。とはいえ一般人はもんじゅそのものを見ることはできないので、その手前の「MCスクエア」という建物で展示物の見学＆お勉強。人がほとんどいなかったせいもあって、急ぎ足ながら職員（研究員？）の方から直接説明を受けることができた。

それまで「高速増殖炉」という名称や「消費した以上の燃料を製造」とかいう謳い文句から、何となくアヤシいものを想像してしまっていたのだが、コンセプトとしては非常に明快なものだということが分かった。私が理解したところによればこんな感じだ：

そのまま燃やせる乾いた薪と、そのままでは燃やせない湿気った薪がある。
数は湿気った薪の方が圧倒的に多いので、捨ててしまうのはもったいない。
そこで乾いた薪を燃やして水を沸かすときに、周りに湿気った薪を並べておいて、
ついでに乾かすことにしよう。

例えは私が考えたものだが、そこまで外してはいないと思う。つまり乾いた薪＝U235,Pu、湿気った薪＝U238、乾いた薪を燃やしながら湿気った薪を乾かす＝U235やPuで発電しながら、発生する中性子でU238をPuに変換する。消費した以上の燃料を生み出すというのは、10本燃やす間に11〜12本くらい乾かすことができる、という程度の意味。摩訶不思議なプロセスで燃料が”増殖”するわけではない。

あと熱の運搬に「液体ナトリウム」という、日常的感覚からはかけ離れつつも基礎的な化学知識で危険性が理解できる代物を使わなければいけない、という点がすごく不安だったのだが、実は運用上優位な点もいろいろとあるらしい。沸点が高いので常圧のまま運用できるとか、熱伝導率が高いので発電効率も高いとか、金属との相性が良いので配管の腐食が起こりにくいとか……。しかしそれでも事故が起こったのは事実なわけで、やはりナトリウムの扱いが一番難しいところなのでしょうか？と尋ねたところ、「様々な困難を克服して今がある」というような回答が返ってきた。また「ナトリウム漏れは、技術屋的には『ああ漏れたか』という程度の話だ」とも。……ここからは完全に私の想像なのだが、おそらく現場の研究員としてはナトリウム漏れ事故も「ナトリウムが漏れた、ではどうしよう、温度計が原因だから温度計を改良しよう」とかいう通常の技術的課題という認識でしかなく、「ナトリウムが漏れた、ではもう駄目だ失敗だ」的な世間の反応がもどかしいのではないだろうか。

もちろん技術的に可能だからといって、無限に税金を投入し続けて良いという話にはならない。本当に割に合うのかという議論は必要だ。また周囲の住民からすれば、何をどう説明されたところでそう簡単に割り切れるものではないだろう。しかしともすれば得体の知れない巨大事業と見られがちな高速増殖炉事業も、その裏側には確実に人間の営みが存在する。それをはっきりと感じ取ることができたのが収穫だった。

……

敦賀半島には海水浴場がたくさんあり、もんじゅへ向かう途中の道のりでも浜辺を埋め尽くす大勢の海水浴客を見ることができた。しかし半島の先端にあるもんじゅに近付くにつれて人も車も少なくなり、MCスクエアの駐車場は閑散としていた。皆もっともんじゅについて知るべき！と思った。

インストールまで。標準の設定では sshd と ftpd しか有効にならない。

古い Qpopper が動いているサーバでPOP3サービスに対する攻撃を防御する必要が生じたので、POP3用の設定を追加した。

blockhosts.cfgの設定

LOGFILES に maillog のパスを追加。

LOGFILES = [ "/var/log/secure","/var/log/maillog", ]

ALL_REGEXS にログパターンを追加。qpopper用のパターンは標準で含まれてはいるが、実行ファイルの名称（＝ログに記録されるプログラム名）が異なっていたのと、不正パスワード以外の失敗パターンも捕捉したかったので、下記のように追加した。

#    "qpopper-Fail":
#        r'{LOG_PREFIX{qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] Password supplied ',

    "qpopper-Fail-Password":
        r'{LOG_PREFIX{in.qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] Password supplied ',

    "qpopper-Fail-Access":
        r'{LOG_PREFIX{in.qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] Access is blocked ',

    "qpopper-Fail-PAM":
        r'{LOG_PREFIX{in.qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] PAM authentication failed ',

ENABLE_RULES の正規表現を修正して、先ほど追加した qpopper 用ルールを有効にしておく。この設定を明示的に行わないと sshd と ftpd しか有効にならないので注意が必要。

ENABLE_RULES = r'(?i)(sshd|.*ftpd|qpopper).*'

テスト

dry-run オプションを付けて実行。

sudo blockhosts.py --verbose --dry-run

hosts.allowの修正

blockhosts.py の行にqpopperを追加する。

in.qpopper, in.proftpd: ALL: spawn /usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 : allow

マイページの「報告したチケット」の中で、終了したチケットが表示されて鬱陶しかったので、
app/views/my/blocks/_issuesreportedbyme.rhtml
を修正。:conditionsの中に以下の条件を追加。

#{IssueStatus.table_name}.is_closed=0

夜眠れなかったので、たまたま見かけた『どんなにへたくそでも一日後には絵が上手くなる方法:ハムスター速報　２ろぐ』を試してみた。

元スレ主の主張は半ば精神論になっていたので半信半疑だったが、6枚7枚と円を描き続けるうちに、ごく単純で合理的なトレーニングであることに気が付いた。要するにこれは文字通り「手を動かす訓練」なのだ。思った通りに手を動かすことができなければ、どれほど明確なイメージが頭の中にあっても、たとえ円のように普遍的で揺らぎようのないイメージであっても、上手に描くことはできない。逆に言えば明確なイメージの元で延々手を動かし続ければ、やがては適切な手の動かし方を身体が覚える。そして思った通りに手が動き、イメージ通りのモノが描き上がる、という経験は確かに楽しく、私自身10枚のつもりが気が付けば15枚以上描いてしまい、最後の方は「真っ直ぐに線を引く練習」などを延々繰り返していた。

プログラミングの世界では有名な格言がある：「プログラムは思った通りには動かない。書いた通りに動く。」絵についても同じなのかも知れない：「絵は思った通りには描けない。手を動かした通りに描ける。」

はてブのコメントを見るとプログラミングの”Hello World”に例えた方もいらっしゃっるようだが、私の感覚では、（特定のプログラミング言語の）基本的な制御構造をエディタ上ですらすらと書く練習、に相当するような気がする。プログラミングそのものの技量にはならないが、それ以前に必要となるスキルで、特に新しい言語を学ぶ場合には真っ先に習得する必要がある。