自宅のサーバ経由でメールの送信するプログラムを作っていて、ログを見ていたら、次のようなメッセージが出ていた

fatal: main.cf configuration error: mailbox_size_limit is smaller than message_size_limit

mailbox_size_limit を大きくしておかなかったのでログがはかれていた

そんな訳で、/etc/postfix/main.cf　を再編集

message_size_limit = 104857600　と設定していたので、直ぐ下に、
mailbox_size_limit = 104857600　と記載し、再起動

そしたら、今まで溜まっていた改竄監視ツールのメールが一気に流れた・・・orz


mailq  でキューを確認

postcat -q　キューID　で、中身を確認したら、それでも、まだ監視ツールのメールが１００以上ある・・・orz

postfix を止めて、

postsuper -d ALL　で全削除！

[0回]

うちのサーバのCPUが、ほぼ１００％で、kacpidが98%占めてる・・・

そんなわけで、http://piro791.blog.so-net.ne.jp/2008-12-18　を参考に


・・・・・数日、立つとまたもや、駄目・・・・

他のページを見てみたけど、そのページではUSB系が悪さをしていたみたい

うつのサーバのキーボードは、USBなのですが・・・orz

んー


んー


んー

要らん

kacpid　がなんなのかさえ調べるのがダルイので、とりあえず要らん

acpi=off　

と指定し、リブート

うん、好調！


05/23　追記
またもや、kacpid　がCPUを独占していた・・・
ん～、なにやら、CPUを独占するだけの条件がありそう

試行錯誤で、気になっていたことなるので、試しに

それは、Tripwire　が起動し、チェックをしていると、kacpid　もいつの間にか、CPUを独占している気が・・・

なので、Tripwire　を起動させないように、変更してみた

そして、現在3日目、kacpid　は大人しくしております

成功か！？

5/29
やっぱり駄目だったので、追記

なにやら、カーネルにバグがありそう・・・（推測）

カーネルのアップデートしようと思ったけど、面倒なのでやめ
なので、再起動をさせ、現状入っているカーネルでカーネルを別のカーネルに選択して起動

起動して、現在でで、4日目
今のところ無事・・・

現在は、Linux サーバ名称 2.6.18-92.1.22.el5　です

5/31追記
さらにダメ・・・

んー、じゃー熱暴走かな？
とりあえず、サーバを止めて、ファンやら、なにやらお掃除

そして、ふたをあけて、しばらく放置

そして起動

・・・・やっぱり、熱暴走だったのか・・・
6/8現在、特にCPUの独占をしている様子はない

[0回]

参考URLをみながら、Eclipse3.4をいれてみたけど、使いにくいので、

前から使っていた3.2で、未だに開発中


http://www.db.is.kyushu-u.ac.jp/rinkou/javaintro/eclipse.html

[0回]

/proc/cpuinfo　

にCPUの情報が記載されているはず

[0回]

CentOS5 って、root で crontab がデフォルトでは使えないのね・・・

CentOS4は、Fedora に比べてコマンドは少なかったし・・・


crontab の話題になったことろで、

crontab [ -u ユーザ名 ] { -l | -r | -e }

-u どのユーザがcrontabを設定するのかを指定します。省略した場合はcrontabコマンドを実行したユーザで設定されます。

# crontab -u tamo -l
1 * * * * echo "cron test"-l オプション
-l オプションは、現在の crontab を標準出力へ表示させる。

$ crontab -l
1 * * * * echo test-r オプション
-r オプションは、現在の crontab を削除する。（全ての設定が削除されるので、使用は十分に注意してください）

-e オプション
-e オプションは、環境変数 VISUAL もしくは EDITOR で指定されているエディターを使って、現在の crontab を編集するのに使われる。編集終了後、 変 更された crontab は自動的にインストールされる。
 

[0回]