今度は CPU 切替器が壊れたぽい。まいったなあ。 最近、ラジカセ, モニタ, HDD, AlphaStation XP1000, …… と立て続けに電気機器がぶっこわれて (ぶっこわして) いて、冗談抜きで呪われてそうである。 次はこのサーバがやばそうだ。
まあ、原因はたぶん、90 年代前後に買ったものが一斉に寿命に来たからだろうな。 また次点として俺から電磁波が出てるという案を挙げたい。 なんかね、最近磁気カードのデータが消えまくってるんですよ。 RubyConf のホテルのカードキーとか、通帳とか。
(02:32)
ruby-dev summary ようやく投げた。
予想通り、ruby-talk では selector namespace の話題が爆発中。 これはいつもの「案だけはたくさん出るけど結局何も決まらないパターン」だな、間違いなく。
ちなみに俺は selector namespace には消極的に反対。 だってメチャクチャ濫用できそうなんだもん。
(01:08)
samidare を別のマシンに移動したら見事に動かない。 ruby に -d を付けてみると、「Non-HTTP proxy URI: (RuntimeError)」で concurrent_map が止まってるということがわかった。 発生元は open-uri.rb で、試してみるとこれだけでも出る。
~ % ruby -ropen-uri -e 'URI("http://i.loveruby.net").read'
/usr/local/pkg/ruby/lib/ruby/1.9/open-uri.rb:233:in `open_http': Non-HTTP proxy URI: (RuntimeError)
from /usr/local/pkg/ruby/lib/ruby/1.9/open-uri.rb:688:in `buffer_open'
from /usr/local/pkg/ruby/lib/ruby/1.9/open-uri.rb:193:in `open_loop'
from /usr/local/pkg/ruby/lib/ruby/1.9/open-uri.rb:191:in `open_loop'
from /usr/local/pkg/ruby/lib/ruby/1.9/open-uri.rb:137:in `open_uri'
from /usr/local/pkg/ruby/lib/ruby/1.9/open-uri.rb:590:in `open'
from /usr/local/pkg/ruby/lib/ruby/1.9/open-uri.rb:598:in `read'
from -e:1
こういうことだろうか……。
Index: lib/open-uri.rb
===================================================================
RCS file: /var/cvs/src/ruby/lib/open-uri.rb,v
retrieving revision 1.42
diff -u -r1.42 open-uri.rb
--- lib/open-uri.rb 30 Sep 2005 16:48:46 -0000 1.42
+++ lib/open-uri.rb 2 Nov 2005 20:19:13 -0000
@@ -173,7 +173,7 @@
end
case opt_proxy
when true
- find_proxy = lambda {|u| [u.find_proxy, nil, nil]}
+ find_proxy = lambda {|u| pxy = u.find_proxy; pxy ? [pxy, nil, nil] : nil}
when nil, false
find_proxy = lambda {|u| nil}
when String
(05:23)
chroot 入りの特製 CVS パッケージを作ってたんですけどね。 何度やってもログインすると認証エラーになって、 いったい何がおかしいのかと思ったら……。
deb の作りかたを間違えてパッチが当たってなかっただけでした (泣)
ソースコードを書き換えるだけじゃだめなのね……。 パッチを保存しといたらうまくいった。
これを機に deb の作りかたをちゃんと調べとこうかな。
(02:44)
DNS, SMTP, cvspserver は新サーバに移行した。残るは HTTP のみ。
AMD64 だと何かあるかなーと思ったが、比較的なんとかなっているようだ。 クロックが飛びまくったり cvsup が ioctl でもれなくエラーを吐いたり、 ときたま CVS が SEGV したりするくらいで。
……だめじゃん。
(19:50)
こないだツッコミ SPAM をくらっていらいツッコミ欄を閉じているんだが、 やっぱりツッコミが入れられないと書くほうもつまらない。そろそろ復活させよう。
そこで考えなければならないのが SPAM 対策である。 完全とはいかなくとも、せめて日常に問題がないくらいの対策をとりたい。 何をすればよいのか考えてみる。
ツッコミ SPAM で最も致命的なことは何か。 それは RSS に大量のゴミが混じることである。
日記のツッコミに SPAM が混じっているのは邪魔だが、 致命的とは言えない。消せば済むからだ。
コメントに SPAM が入ることで SPAM に入ってる URL の Google 指数が上がるかもしれない。 これは不愉快ではあるが、単に不愉快なだけだし、短時間で消せば問題ない。 長期的にも、消しておきさえすればいつかは影響も消える。 回復可能ならば致命的とは言えない。
一気に大量のツッコミ SPAM を受けてサーバの負荷が上がるかもしれないが、 所詮個人のサーバにとってはこれも致命的とは言えない。
従って、最も致命的なことは、RSS に大量の SPAM が入り、 こちらではコントロールできないところに拡散してしまうことである。
また、ツッコミ SPAM は「大量」のときに最も問題になる。 そしてここで言う「大量」とは、時間に対して相対的に多いことである。
従って対策は二通りある。すなわち絶対数を減らすか、時間のほうをのばすか。 ありがちな対策はすべて前者に含まれるので、後者の方法について考えてみた。
話は簡単で、短時間で大量にツッコミが入ったときは、 それを RSS に入れるまでの時間をのばす。 短時間にたくさん来れば来るほど RSS に入るまでの時間をのばす。
これを思いついてから考えてみたんだが、たとえ SPAM じゃなくたって いきなり 500 も 600 もエントリが追加されたら全部読むやつはまずいないだろう。 そう考えるとこの方法って凄く理に適っているのかもしれない。
(07:58)
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2587
ですよ！ Opteron は当然として Athlon64 でも使えるぜ！
(04:45)
サーバ移行して以来、Load Average が 0.1 以上に上がらない。 Athlon64 すげえよ。 まあ、前が Pentium II 300MHz だからってのもあるんだけど。 なんでもかんでも速くて、久しぶりにマシンの速度に感動を覚えた。
(02:07)
これか―――――――っ！
diff -u -r -p cvs-1.12.9/src/vers_ts.c cvs-1.12.9-my/src/vers_ts.c
--- cvs-1.12.9/src/vers_ts.c.org 2004-05-20 12:00:44.000000000 +0900
+++ cvs-1.12.9/src/vers_ts.c 2005-11-12 13:51:57.000000000 +0900
@@ -355,7 +355,7 @@ entries_time (time_t unixtime)
{
struct tm *tm_p;
char *cp;
- int length;
+ size_t length;
/* We want to use the same timestamp format as is stored in the
st_mtime. For unix (and NT I think) this *must* be universal
本家ではすでに直ってるようだ。 つか、コンパイルで警告出てんだから気付けよ。
以下はおまけ。
diff -u -r -p cvs-1.12.9/diff/util.c cvs-1.12.9-my/diff/util.c
--- cvs-1.12.9/diff/util.c.org 2003-02-03 04:52:38.000000000 +0900
+++ cvs-1.12.9/diff/util.c 2005-11-12 13:36:01.000000000 +0900
@@ -235,7 +235,7 @@ begin_output ()
close (pipes[0]);
}
- execl (PR_PROGRAM, PR_PROGRAM, "-f", "-h", name, 0);
+ execl (PR_PROGRAM, PR_PROGRAM, "-f", "-h", name, (char*)0);
pfatal_with_name (PR_PROGRAM);
}
else
diff -u -r -p cvs-1.12.9/src/subr.c cvs-1.12.9-my/src/subr.c
--- cvs-1.12.9/src/subr.c.org 2004-06-09 23:52:39.000000000 +0900
+++ cvs-1.12.9/src/subr.c 2005-11-12 13:48:42.000000000 +0900
@@ -1305,7 +1305,7 @@ format_cmdline (const char *format, ...)
dellist(&pflist);
free(b);
error (1, 0,
-"internal error: unknown integer arg size (%d)",
+"internal error: unknown integer arg size (%ld)",
length);
break;
}
@@ -1348,7 +1348,7 @@ format_cmdline (const char *format, ...)
dellist(&pflist);
free(b);
error (1, 0,
-"internal error: unknown floating point arg size (%d)",
+"internal error: unknown floating point arg size (%ld)",
length);
break;
}
diff -u -r -p cvs-1.12.9/src/wrapper.c cvs-1.12.9-my/src/wrapper.c
--- cvs-1.12.9/src/wrapper.c.org 2005-11-12 14:11:57.000000000 +0900
+++ cvs-1.12.9/src/wrapper.c 2005-11-12 13:52:41.000000000 +0900
@@ -245,6 +245,7 @@ wrap_unparse_rcs_options (char **line, i
* Remove fmt str specifier other than %% or %s. And allow
* only max_s %s specifiers
*/
+static void
wrap_clean_fmt_str(char *fmt, int max_s)
{
while (*fmt) {
これで型関係のエラーは全部潰したはず。
(15:31)
くっそー、Debian でも 11/4 に fix されてる。一週間ちょっと遅かったか。
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329127
(15:54)
http://jp.rubyist.net/magazine/?0011
るびま #11 出ました。
HexStruct の記事はもっと短くなると思ったのに、 えらい長くなってしまった。 来月は休もうかなあ……。
(22:03)
新サーバの時計がすごい勢いでズレまくり。 1 日 1 時間くらいのペースでずれてる。 ntpd が悪いのか、OS が悪いのか、ハードウェアクロックが悪いのか、原因がわからん。 サーバの時計がずれてると地味に痛いんだよなあ。
(22:04)
SPAM だと思って捨てかけた中国語っぽいメールをよくよく見てみたら日本語だった。 ていうか、RHG を中国語に翻訳したいっていうメールだった。 エンコーディングが GB2312 だから変だったのか。
うーむ…… ISO-2022-JP でメールを出しても読めるんかな。 それとも英語のがいいんだろうか。
(23:58)
時計のずれがどうしてもなおらないのでひとまずメインマシンをサーバにしたてることにする。AMD64 マシンが複数あって助かった。このスキに原因を調査して根治をはかりたい。
…のだが、これをチャンスとばかりに Supermicro の H8SSL-i を買ってしまいそうな俺がいる。
/var/log/ntpd
21 Nov 02:10:35 ntpd[19926]: synchronized to *************, stratum 2 21 Nov 02:15:53 ntpd[19926]: time reset -4.292346 s 21 Nov 02:24:28 ntpd[19926]: synchronized to *************, stratum 2 21 Nov 02:31:59 ntpd[19926]: time reset -1.556835 s 21 Nov 02:40:34 ntpd[19926]: synchronized to *************, stratum 2 21 Nov 02:48:11 ntpd[19926]: no servers reachable 21 Nov 04:49:49 ntpd[19926]: synchronized to *************, stratum 2 21 Nov 04:49:20 ntpd[19926]: time reset -29.068455 s 21 Nov 04:56:52 ntpd[19926]: synchronized to *************, stratum 2 21 Nov 05:04:24 ntpd[19926]: no servers reachable (現在のクロック： JST + 00:24:40)
どう見ても再発しています。本当にありがとうございました。
だいたい時刻合わせるたびに 3 秒とか 4 秒とか戻してるのはどういうことだ。 5 分に 1 秒の割合でずれてるじゃんか。
しかも今わかったのだが、ハードウェアクロックはずれてないんだな。
% date 2005-11-23 (水) 18:23:05 JST % sudo hwclock --show Wed Nov 23 17:58:49 2005 -0.941976 seconds
システムクロックのほうが 25 分進んでる。 ということはつまり、カーネルが勝手に進んでるだけでハードウェアの問題ではない。
で、いろいろ調べてみた。K8 の Cool'n'Quiet が原因じゃね？ とかいろいろ見付かるものの、結局のところ何が原因なのかよくわからない。 Genntoo のフォーラムにも似た記事があったけどやっぱり何なのかよくわからない。
http://forums.gentoo.org/viewtopic.php?t=191716
困った。
とりあえず powernow-k8 と cpufreq-ondemand モジュールが 入ってなかったので入れてみた。
(19:11)
これっぽい。
http://umiushi.com/~wac/linux/#amd64
うう、すげえ嫌な感じ……。
(19:20)
カーネルを 2.6.14-2 に入れ換えてみた。 どうなるかな……
これも Cool'n'Quiet 対策の成果なのか、 /proc/cpuinfo の情報がダイナミックに変化してる。
暇なとき
tukumo:~ % cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 1004.646 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 2010.53 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 1004.646 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 2010.53 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp
忙しいとき
tukumo:~ % ruby -e 'while true; end' & [1] 3748 tukumo:~ % cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 2210.222 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 4423.16 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 2210.222 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 4423.16 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp
暇なときと忙しいときとでは cpu MHz と bogomips が違う。 これはおもろいな。
(22:38)
いきなりツッコミ SPAM かよっ
さて、どう対処するのが効果的だろう。 とりあえず一ヶ月以上昔にはツッコミ禁止として、 そこにコメント投げてくるやつは自動的にブラックリストにのせる、 みたいのをやってみるかな。それ以上の対策は傾向を見て考えよう。
(18:42)
ツッコミ SPAM 消しとかないとな。 とりあえず tdiary-comment-clean.rb ……を、 リライトしたやつでザックリ消す。消す。
はい、.tdc ごと消えました。
うぎゃー！
……いやいや、毎日フルバックアップをとっておいてよかった。 本当によかった。つくづくよかった。
(22:00)
Haskell のパーサコンビネータがやばいくらい面白い。これはいいなあ。 花谷さん訳の「Parsec, 高速なコンビネータパーサ」を見ながらやってます。
http://www.lab2.kuis.kyoto-u.ac.jp/~hanatani/tmp/Parsec.html
(22:50)
Haskell 標準ライブラリの Text.Html の出力がなんか嫌だ。 エレメントに大文字使うな！ インデントなんてせんでいい！
~ % cat html.hs
import Text.Html
main = putStr . show $
[ (h1 $ stringToHtml "string"), (p $ stringToHtml "body") ]
~ % ghc-6.4.1 -package text html.hs -o html && ./html
<H1>
string
</H1>
<P>
body
</P>
この pretty print を止める方法はないものか……。
(22:58)
おいおいおい、href 作っても URL はエスケープしてくれないのかよ。 なんだよそれ。ほとんどそれだけを当てにしてライブラリ使ってたのに。
Text.Html 捨て！
URI を Network の下に置くのはいかがなものか。
それはともあれ、URL が含まれてるテキストを Parsec でパースしたいんだけど、 なんかうまい方法はないのだろうか。こんなのしか思いつかないよ……。
url = do a <- string "http"
b <- option "" (string "s")
c <- string "://"
d <- many1 urlChar
return $ concat [a,b,c,d]
urlChar = alphaNum <|> oneOf ";/?:@&=+$,-_.!~*'#%" -- omit '(' and ')'
(02:53)
とりあえず今日の成果
~/c/xxxxxx % cat src = テストページ 普通のパラグラフな感じで まあ普通の WikiName だったり http://www.example.com だったり * 箇条書き * あいてむ * アイテム # 番号付きだ # ナンバー :単語:説明かもしれない :Alpha:DEC :SPARC:Sun :Itanium:Intel :Opteron:AMD ~/c/xxxxxx % nkf -e src | ./compile <h1> テストページ</h1> <p>普通のパラグラフな感じで</p> <p>まあ普通の <a href="WikiName.html">WikiName</a> だったり <a href="http://www.example.com">http://www.example.com</a> だったり</p> <ul><li> 箇条書き</li> <li> あいてむ</li> <li> アイテム</li> </ul> <ol><li> 番号付きだ</li> <li> ナンバー</li> </ol> <dl><dt>単語</dt> <dd>説明かもしれない</dd> <dt>Alpha</dt> <dd>DEC</dd> <dt>SPARC</dt> <dd>Sun</dd> <dt>Itanium</dt> <dd>Intel</dd> <dt>Opteron</dt> <dd>AMD</dd> </dl>
うーむちょっと余分な空白が……。
(03:06)
■
向井 [それ以前に Text.Html は HTML 3.2 なのが……。
そろそろ 4.x か XHTML になってほしいところではありますが。]
■
青木 [あ、やっぱりそうなんですか。
このへん誰も使ってないんですかねえ。]
■ 向井 [補足ですが、 WASH を使えば xhtml が生成されます。]
■
青木 [なるほど。WASH のほうがよさげですね。
できるだけ外部ライブラリは使いたくなかったんですが、
これはしょうがないかなあ。]
■
shelarcy [実は個人的な XHTML 対応版があります。積極的に開発陣にアピールしないと置き換えられなそうですが……
http://www.cs.chalmers.se/~bringert/darcs/haskell-xhtml/]
■
shelarcy [あっ、Björn Bringert さんによる、ね。
> 個人的な XHTML 対応版]
WASH コンパイル中……。
まさか GHC にメモリを使い切られるとは思わなかった。 X が反応せずどうにもならなくなってリセットボタンプチですよ。 どうも最適化でメモリを使いすぎてたらしい。 しばらく ghc -O2 は使用禁止のうえ nice -n 19 の刑。
(19:27)
Copyright (c) 2002-2007 青木峰郎 / Minero Aoki. All rights reserved.
■ 青木 [ツッコミてすと]