2007年6月アーカイブ

plaggerからMixiのメールが来ない。
cronで1時間に一回実行しているのだけれど、プロセスががんがん溜まっている。
で、原因を調べてみたらBbsのところで無限ループしている。
とりあえず、Mixiのページを見ながら正規表現を見直し。本当は、Mixi側が変わった場合でも無限ループしないように直すべきなんだろうけど。
あと、本家(?)のWWW::Mixiは0.50-pre2とかまで上がっているらしく、そちらでも対策されているようだ。
私の手元にあるのは0.48と0.49で、そこだけでも結構差分があって面倒なので、今回も0.48からの差分。
時間を取って最新ベースにしたほうが良いんだろうけどな～。
と言うわけでパッチ

今回の件で、plaggerが無限ループしたりすると、cronから毎時起動されてどんどんプロセスが増えてしまうことがわかったので、対策を入れる。
FreeBSDには/usr/bin/lockf と言うコマンドがあり、これを使うとファイルのロックを獲得できたときだけコマンドを実行する、と言うことができるのでcronに仕込むことにした。

55 * * * *       /usr/bin/lockf -t 0 -s /tmp/plagger.$USER /usr/local/bin/plagger -c $HOME/plagger/config.yaml > /dev/null 2>&1

みたいな感じ。最初、-tオプション(ロックのタイムアウト)を付け忘れてしまい、plaggerは一つしか起動しなかったものの、lockfがたくさん起動してしまった。-t 0をつけることで、ロックを獲得できなければその場で諦めてくれる。

FreeBSD-users ML で、以下のメールが流れた。
xorg の更新後の periodic
どうも、最近dailyで来るメールに、portauditの出力が2回入ってるな～と思っていたのだが、これのせいらしい。
そこで、/etc/defaults/periodic.conf を見ると以下の行があったので、

local_periodic="/usr/local/etc/periodic /usr/X11R6/etc/periodic"

/etc/periodic.confに以下の行を追加。

local_periodic="/usr/local/etc/periodic"

鶴谷さんも書いてるけど、ここはOSの/etc/defaults/periodic.confを直してもらいたいところ。
はっ、今回はmergemasterをやっていないからそのせい？と思って/usr/srcを見てみたけど、やはりまだ直っていない模様。

MovableTypeのtrackback(mt-tb.cgi)に、2007/6/14の2:01～2:14の間に258回のアクセスがありました。
送信元のアドレスは258回のアクセスに対して233であり、多岐にわたっていました。
comcast.net, rr.comが多いように見えましたが、aol.comなどもありました。

この攻撃により、MovableTypeのbackendにしているPostgreSQLが悲鳴を上げ、ルータも兼ねていたのでほとんどの機能が使えなくなりました。
しょうがないので光終端装置とのLANケーブルを抜き、コンソールからのrootログインを試みました。
かなり時間がかかったものの、なんとかログインできました。
その間もHDDはがりがり言っていて、コンソールにはPostgreSQLの接続が設定値を超えているとのエラーが出ていました。
ps で見てみるとmt-tb.cgiと、postgresqlのプロセスがたくさんいましたが、ケーブルも抜いたしそのうち落ち着くと思ってほっておきました。
その間に、mt-tb.cgiの名前を変えて、postgresql.confの中の

max_connections = 100

の max_connectionsを10にしました。
やがて落ち着いたので、postgresqlを再起動し、mt-config.cgi の TrackbackScript を修正して、blogの再構築を実施しました。
最後にケーブルを戻して、pppを再起動してなんとか復旧となりました。

しっかし、迷惑な話だなあ。

お仕事で、gdbを使ってクロスプラットフォームのリモートデバッグをやったのでメモ。
gdbについてはマニュアルを見てもらうとして、リモートデバッグの手順を書いてみます。

準備

• ターゲットマシンと開発ホストがシリアル又はLANで繋がっていること
• 開発ホストにターゲットマシン用のクロスgdbがインストールされていること
• ターゲットマシンにgdbserverがインストールされていること
• 開発ホストにデバッグ対象の実行ファイルとソースがあること（-ggdb つきでコンパイルされていること)
• ターゲットマシンにデバッグ対象の実行ファイルがあること

手順

1. ターゲットマシンでデバッグ対象のプログラムとgdbserverを起動する
• 実行ファイルが直接起動できる場合

# gdbserver 0.0.0.0:5555 prog arg...

※ 5555 の部分は任意のポート番号。(LANの場合。シリアルの場合は、0.0.0.0:5555の代わりにシリアルのデバイスファイル名)
※ prog arg... の部分は、デバッグ対象の実行ファイルとコマンドラインパラメータ
• 実行ファイルが直接起動できない場合
1. GUI等から実行ファイルを起動する
2. ps等でデバッグ対象のPIDを調べる
3. gdbserverを起動する

# gdbserver 0.0.0.0:5555 --attach PID

2. 開発ホストでgdbを起動する

# gdb prog

※ prog はデバッグ対象のプログラム。gdbはターゲット環境用のもの。
3. gdb上でリモートデバッグを指示する

(gdb) target remote x.x.x.x:5555

※ x.x.x.x は ターゲットマシンのIPアドレス。
4. あとは、普通にgdbとして使えば良い
5. デバッグをやめるときは detach と入力する。