SVX日記

2004|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|

2005-11-09(Wed) NonCooperative Linux for Bind

  昨日、直ったと思ったBindだが、実はぜんぜん直ってなかった。怒涛のシスログ攻撃はなくなったが、相変わらずBindのCPU使用率は100%を割らない。怒涛のシスログ攻撃は暴走の副産物に過ぎなかったみたいだ。そりゃ、よく考えたら、gettimeofdayの百連打が収まらなければ、問題の解決になるわけがないよな。やっぱり、gettimeofdayがムチャな値を返すのが原因か?

  一体何をやっているんだろうと思って、CPUを食いまくっているBindの子プロセスにstraceをアタッチしてみる……

gettimeofday({1131896487, 3949351405}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [HUP INT TERM RTMIN], NULL, 8) = 0
gettimeofday({1131896487, 3949351701}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [HUP INT TERM RTMIN], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], [HUP INT TERM RTMIN], 8) = 0
gettimeofday({1131896487, 3949352340}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [HUP INT TERM RTMIN], NULL, 8) = 0
gettimeofday({1131896487, 3949352635}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [HUP INT TERM RTMIN], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], [HUP INT TERM RTMIN], 8) = 0
gettimeofday({1131896487, 3949353278}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [HUP INT TERM RTMIN], NULL, 8) = 0
gettimeofday({1131896487, 3949353571}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [HUP INT TERM RTMIN], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], [HUP INT TERM RTMIN], 8) = 0
gettimeofday({1131896487, 3949354214}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [HUP INT TERM RTMIN], NULL, 8) = 0
gettimeofday({1131896487, 3949354508}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [HUP INT TERM RTMIN], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], [HUP INT TERM RTMIN], 8) = 0

  やはり、怒涛のgettimeofday攻撃である。ちなみに、coLinuxというものはインストールしたディストリビューションのカーネルを使わない。WBEL3をインストールしても、WBEL3のカーネルは使われないのである。coLinuxはWindows上で動くためのカスタムカーネルを使うことで、LinuxをWindows上で動かしている。当然ながら、カーネルに依存するモジュールもcoLinux側に添付されている。VMwareとはそのヘンがちがうのである。しかし、アレだ。2.4、2.6の違いがあっても、カーネル以外の部分はそのままで動くというのは意外だったなぁ。つまり、WBEL3は2.4カーネルとの組み合わせられているが、カーネルだけを2.6にしても、ほとんど何の問題もなく動くということである。まぁ、システムコールの動作に互換性があれば、不思議でもなんでもないが……

  ……などというコトを考えながら、なんとなくググっていたら、こんなカキコミを見つけた。そういえば、最近は、仕事の時間中、英語の文章を読まざるをえないコトが多いから、苦がなくなったなぁ……なるほど、やっぱりカーネルのバグっぽい。既知の問題だったのね。coLinux上でBindを使う人は少ないのか?

  ココには最新のスナップショットで、やっとこさ直ったようなことが書いてあるが、家のゴミにインストールしたcoLinuxの0.6.2では、この現象は発生しなかった。どこで直っているのかは知らないが、0.6.2に上げるかなぁ……。でも、coLinuxの0.6.1のカーネルベースは2.4.26、0.6.2のカーネルベースは2.6.10なんだよなぁ。WBEL3のカーネルは2.4.21、どうしたって0.6.1と組み合わせてる方が相性が良いと思うんだよねぇ。それに職場のXPではcoLinuxのインストールに失敗しまくっているから、せめて手元のcoLinux環境を壊すことだけはしたくないんだよなぁ。

  本来であれば、自分でカーネルにパッチを当ててしまいたいところだが、coLinuxのカーネルはあくまでWindowsアプリである。どんな環境でコンパイルできるのかもわからない……ムリヤリBind側にパッチを当ててしまおうかなぁ。アレだろ? Bind的に、時刻が負になったり、戻ったりしなきゃ大丈夫なんじゃないの? 違うかな?

  <かきかけ>