最近必要にせまられて、 テキストファイル中の語句を統一するのに便利なツール(chkwd.rb)を作ってみた。

出るとついバージョンアップしてしまう一太郎。 とうとう11だ(というかATOK14というべきか)。 メーカーは言わずと知れたジャストシステム。

Webのアクセス分析にはanalogを使っている。

アイ・オー・データ機器のUSB-GPSを使うべく、 ライブラリを作り始めた(が、挫折)。

MIDIソフトウェア関連なぞ、ちらほら。

ダウンロード販売の手軽さに負けて、B's Recorder Gold5を購入。

daemontools

qmailの作者が作ったツールで、daemontoolsというのがある。 プロセスを起動、監視し、ログを録るツールである。 これを使うと、落ちたデーモンを自動的に復活させることができる。 まあ、普通は頻繁にデーモンが落ちるようならその原因を追及するのが王道である。 ただ、原因がローカルにない場合もままあり、 その場合は大変重宝する。 私の場合、典型例がseti@homeである。

例の「地球外生命体が発信したと思われる電波を探す」 プロジェクトのクライアントなのだが、 なにせクライアントが400万に届こうかというプロジェクトなので、 時々サーバーの反応が鈍くなる。 すると、 解析用のデータを入手できなかったクライアントが落ちてしまう。 以前は気がついたときに人手でチェックしていた。 しかし、FreeBSDのマシン3台にWindows 2000のマシン1台となると、 すべてがちゃんと動いているかどうか確認するのもなかなか面倒だ。 そこで、FreeBSDのマシンにはdaemontoolsを入れ (というか、tinydnsを入れた関係で既に入っていたのだが)、 これでseti@homeのクライアントを起動するようにした。

で、その後しばらくしてからMRTGを導入し、 ロードアベレージの監視を行っていたところ、 みごとにdaemontoolsで自動的にプロセスを再実行する状態を記録できた。

監視対象のマシンはデュアルCPUなので、 seti@homeをふたつ走らせている。 ロードアベレージの点から言えば、 seti@homeしか動いていないとっても過言ではないだろう。 CPUパワーが余っているようである。 7:00にひとつプロセスが落ち、9:00にもうひとつも落ちた。 クライアントの受け取ったデータによって計算時間が違うため、 計算完了時間にはそれに応じた差ができる。 積もり積もれば2時間くらいの差は簡単についてしまうようだ。 しかし、13:00にはどちらも自動的に再起動している。

レンタルサーバーの解約が目前となったので、 MySQLをレンタルサーバーから自宅サーバーに移動する。 レンタルサーバーのほうはバージョン3.23.39だが、 既に安定版は4.0、開発版は4.1になっている。 portsにあるので、 Makfileに--with-charset=ujisを加えてからmake install。 日本MySQLユーザー会のページを見ながら、 rootのパスワードを設定し、さらにユーザーを追加。

データは、

$ mysqldump -AcC -h pluto -u tomoaki -p > archive.sql

でdumpした。既に不要になった分を削って、

$ mysql -u tomoaki -p < archive.sql

で喰わせてお終い。

あとはWebページ内でMySQLを使う部分で、 ホスト名をpluto.akiyama.nuからlocalhostに変更して一段落。 PHPのバージョンも上げなきゃなあ。

net-snmpをportsで5.1.1_1にバージョンアップしたら、 MIBがかなり変わった。 ディスクの容量関係はStorageになったし、 CPU Loadに関してはどうも見つけられない ((2005年12月2日　CPU LoadはlaLoadだった。))。