「トラブル」カテゴリーアーカイブ

4時過ぎの謎のフリーズ・・・解決

今朝はちゃんとサーバは4時を無事乗り越えたようである。やはりslocateが悪かったようだ。locateコマンドはあまり使わないから支障はないけど、何かがおかしくなっているのだろうな。

何か別の理由でフリーズした後、強制リセットしてファイルが壊れて、その壊れたファイルのせいでslocateが暴走する、とか。何かslocateが不得意とするファイルを誰かが作っちゃった、とか。いろいろと原因は考えられるけど、今のところは全く手がかりなし・・・ locateのDB作成をdebugモードのように実行して(できるかどうかわからないけど)調べれば分かるのだろうけど・・・

いずれにしても、このまま放置するのは危険だから新たなサーバを作ることにしよう。FC5も慣れてきたから、ちょっと早いけどまたサーバの引越しをしよう。Linuxもやはり使い続けているといろいろと壊れてくるものだね。また引越しか〜〜〜、マンドクサイ・・・・

4時過ぎの謎のフリーズ

ここ数日、このサーバが朝になっているとフリーズしている。他のマシンからtelnetしてみても反応がない。かろうじてpingには応答があるけど、これでは何もできない。しょうがないから強制リセットするんだけど、ファイルシステムにいいはずがない。

ログを調べてみても4:05までは何事も無くいつもどおりのエントリが続いている。ログだけ見ててもどうも原因が分からない。4時と言えばcronが起動している時間だからとりあえずcronが怪しいのは分かっているんだけど。。。

で、今日ふとlogwatchにslocateが実行途中でkillされているエントリがキャッチされていることを発見して、slocateを調べてみた。確かに、slocate.cronというファイルがcron.dailyに存在する。そこで、とりあえずコンソールから手動で起動してみる。# /etc/cron.daily/slocate.cron最初しばらくはガリガリとHDDが激しい音を出すけど、あるときにX(GNOME)が突然落ちる。そうするとフリーズの症状が再現される。これが原因に違いない。

とりあえずslocate.cronが何をしているのかを調べてみる。どうも、locateコマンドを実行するときに使うインデックスDBをアップデートしているようである。locateコマンドはたいして使わないから、slocate.cronを実行不可にしてみる。/etc/cron.dailyにて# chmod 644 slocate.cronこれで様子をみてみよう。

bindのupdate後の不具合

久々にサーバを再起動してみたら、起動時にエラーが出てしまった。エラーというよりもワーニングっぽく、xxxx(サーバ名)が/etc/hostsに登録されていないからgrubの起動に問題があるかもしれない・・・とかいうメッセージが表示された。お構いなしにログインしてみたらちゃんと起動してきたけど、何かがおかしい。

ログを調べて見ても特におかしなことはなさそう。外部からもアクセスがあるからサービスは一応正常に上がっているようだ。けど、内部ネットワークからサーバにアクセスできない。pingには応答するけど、一切の名前解決ができていない。

どうやらサーバのbindがupdateされたときに/var/named/chroot/etc/named.confが書き換えられてしまったようだ。named.confに内部ネットワーク用ドメイン定義がないし、named.conf.rpmsaveとして以前のnamed.confがバックアップされている。bindがupdateされてすぐに再起動していなかったから今になって気が付いた、ということらしい。/var/named/chroot/etcにて、# cp named.conf named.conf.rpmoverwrite
# cp named.conf.rpmsave named.conf (上書きするか、と聞いてくるので yes と答える)
と前のnamed.confに戻してあげよう。ちゃんとnamed.conf.rpmsaveの内容を確認してからにしようね。

namedを再起動してみたらばっちり名前解決できるようになりました。

キーボード、マウスの暴走解消

これまでず〜っと悩まされてきたキーボードとマウスの暴走がなぜか今ピタリと収まっている。Geode NX 1750 + 741GX-M + Fedora Core 4 + IC-814-I(ATEN OEM KVM Switch)のコンビネーションが良いのだろうか。

Dell Optiplex GC + FC4 + IC-814-Iではダメだったから、きっと741GX-Mがいいのだろう。というよりも、Optiplex GCがダメなのかも・・・

ただ、ちょっと気を付けないといけないのは、741GX-Mマシンをシャットダウンするときは、KVM Switchを別のマシンに切替えておかないと、なぜかKVM Switchが切り替わらなくなる、と言う不具合がある。まあ、これとキーボードマウスの暴走は比べるまでもないから、こちらのほうがいいんだけどね。

久々のup2date

なぜか最近自動的にup2dateされなくなってしまったのと、サーバが妙に安定しているのでアップデートをサボっていたんだけど、あまり間を空けるといざって時にアップデートが困難になるのが嫌だから、とりあえず手動で(rhn警戒通知ツールをクリックするだけ)アップデートしてみた。

すると、カーネルを含めて色々とアップデートされているみたいだけど、abiwordの依存性チェックで引っかかる。これだからアップデートを怠ると苦労するんだよ〜、と思いつつもまずはカーネルだけをアップデートしてみる。こちらは問題なく完了して、久々にサーバを再起動してみる。

問題なく再起動してきて、今度はabiwordとlibwpd関連のパッケージのチェックを外してアップデートしてみると、これもうまく行く。どうやらbugzillaにもあがっているバグのようで、abiwordとlibwpdのバージョンに不整合があるようだ。ま、これはアップデートをサボっていたことが原因ではなさそうで、たまたまタイミングが悪かったようだ。

abiwordとlibwpdのアップデートはしばらくお預けとしよう。

Filesystem、実は大丈夫

昨日のように、長いこと不具合無く動いているサーバのfilesystemが実はズタズタボロボロ・・・なわけは無いだろう、と思ってよ〜〜〜く考えてみた。

そもそもFedoraはLVMを導入しているから、/dev/sda2とパーティションを指定していても、実際はVolGroup00と言うvolume group (VG) に属するLogVol00とLogVol01というlogical volume (LV) が存在するわけだ。LVが従来のパーティションと言う位置づけになる。そうすると、filesystemはLVに存在するはずだから、いきなり# e2fsck -f /dev/sda2とやってもうまくいかないだろう、と。

そこで、LVを指定して、# e2fsck -f /dev/mapper/VolGroup00-LogVol00とやってみたら・・・
なんと、1つもエラーがでることもなく、ものの数分で終了。うまくいくじゃないですか。よって、本番機のfilesystemはいたって正常だったわけだ。

だいぶLVMの勉強が進んできて、なんとなくパーティションの拡張が出来たような状態まで漕ぎ着けることができた。まだ出来上がったHDDでシステムを起動していないからなんとも言えないけど、今のところ順調にきている。うまくいったらその方法とともに報告することにしよう。

Filesystemが危険な状態に・・・

パーティションを拡張しようとここ2、3日かかりっきりだけど、もういやというほどe2fsckしている。パーティションの拡張作業中だから・・・とさほど気に掛けていなかったけど、とっても長い時間掛かるし、見たことのないエラーがわらわらと出力される。

ふと、これはファイルシステムが壊れ掛かっているからパーティション拡張作業が難航しているんじゃないか? e2fsckが延々と掛かるのではないか? と思うようになった。

試しに、本番ディスクのミラーを取り出して、別のマシンに接続してRescue CDで立ち上げてみた。こういうときにARAID99-2000は威力を発揮するな。まず最初に# e2fsck -f /dev/sda2としてみたら、group descriptorがおかしいとか、superblockのジャーナルがおかしいとか言われる。これはfilesystemが相当怪しそうだ。とりあえず# mke2fs -S /dev/sda2としてsuperblockとgroup descriptorの修復を行ってみる。そうするとinodeのresizeが無効だ、みたいなことを言われるけど正面突破してe2fsckしてみる。そしたらワラワラとエラーがでてくるじゃありませんか。

もうすでに2時間は経過している。これは明日の朝まで放っておくしかないかな。それにしても早く手を打たないと、filesystemがぶっ壊れるのは時間の問題だ!

ファイルシステムが壊れる

今朝、気がついてみればなぜかwebmailがログインできなくなっている。一応うまく動いているようだけど、ちょっとだけ動作が緩慢な気がするからリセットすることにする。

リセットしたらなんとXが立ち上がらない。その代わりにテキスト画面が表示され、「Xの起動に失敗したからログを調べるなりして対処しなさい。手を打ったらGDMを立ち上げなさい。」みたいなメッセージが表示されている。文字化けしていて分からないけど、この画面を終了させる選択肢が一つしかない。とりあえず押してみたら、真っ暗な画面に・・・

しょうがないからCtrl+Alt+Delを押したらshutdownプロセスに入ったけど、なにやらいっぱい[Failed]が表示されてシャットダウンは終了した。これだけFailedが出るとさすがに不安になるけどとりあえず起動してみる。今度はinodeの不整合が発見され、手動でfsckしろ、とのこと。rootのパスワードを入力してメンテナンスモードに入る。以前は確かデバイスを指定しなきゃいけなかったんだけど、FC3では# fsckだけでちゃんと/dev/VolGroup00/LogVol00を修復し始めた。やれやれ、と思ったら今度はいろいろとエラーが発見され始めた。そして次から次へと○×△が壊れているけど直すか?って聞かれるからとりあえずyを押してみたけど、これは判断つかないよ。「はい」としか答えようがないよね。

で、yを20回くらい押し続けた・・・ 前回こんな感じではいはい押していたらしまいにはファイルシステムが全壊したことがあったっけ・・・ なんて遠い目をしていたらようやくfsckが終わって手動でrebootせよ、との指示。恐る恐るリブートしてみたら、奇跡的に立ち上がってきた! 今日は運が良かった。。。

とはいっても途中で破損したinodeがあるから破棄するか? とか、重複したinodeがあるから破棄するか? とかいろいろと危険な質問に「はい」で通してきちゃったからいくつかのファイルは壊れているんだろうな。途中でgaim関連のファイルとか何かのlanguage extensionのpythonスクリプトも表示されたからこれらも壊れているっぽい。

早いうちに別マシンに重要なファイルをバックアップして、次期サーバを用意しなければ・・・

地震でサーバ倒壊

今日の地震は大きかった。この地域は震度5弱だったみたいだけど、マンションの11階のゆれはもっと大きいからなぁ。と言うのも、このゆれでサーバとその上に乗せていたRAID装置が転倒してサーバが死んでしまったのだった。

RAID装置は転倒のショックでHDDトレイが少し飛び出てて、接続されていない状態になってた。と言うことは、HDDの書き込み中だったときだったら・・・ と、想像したくない事態に陥っているのかも・・・ 少なくともキーボードとマウスからの反応はないみたいだけど、サービスはかろうじて動いているようだから、急いでtelnetしてrebootしてみた。

恐る恐る再起動を見守っていると、やっぱり起動してこない (T_T)
スワップ領域を有効にしているあたりでハングアップしているみたい。HDDがいきなりオフラインになっちゃったんだからこれもある意味無理も無い。とりあえず runlevel 3で再起動してみたらHALdaemonの起動まではうまくいったから他のマシンからtelnetしてみた。

とりあえず# swapoff /dev/VolGroup00/LogVol01
# mkswap /dev/VolGroup00/LogVol01
# swapon /dev/VolGroup00/LogVol01
としてスワップ領域の再作成をしてみた。

でも、それでも起動してこない。起動プロセス中の各サービスの実行からログイン画面に移る前にハングアップしている。HALdaemonの起動の次はsshの起動だったからsshの自動実行を止めてみたけどそれでもだめ。最後はspamassassinだけど、それは関係なさそうだ。そうすると、その次は/etc/rc.d/rc.localの実行らしいんだけど、その中にはDiCEの自動実行設定があった。試しにDiCE自動実行設定をコメントアウトしたらちゃんと起動するようになった。Runlevel 5 も問題ない。

地震被害からの復旧は完了したけど、どうもDiCEは真剣に調べないといけないようだ。

またサーバ死亡

Evolutionでメールを見ようと思ったらフリーズしてしまった。そういえば前もそんなことがあったなぁ。このように一瞬にしてフリーズするパターンと、徐々に機能が使えなくなって死んで行くパターンの二つがあるなぁ、どうも。これは別の原因なのか、同じ原因の2つの症状なのか???

しかたないのでリセットしたんだけど、そういえばマウスが暴走しまくるからカーネルパラメータにacpi=off
psmouse.proto=bare
を追加していたんだけど、最新のFC3ではこれらがなくてもマウスは暴走しないことが分っているからこれを外そう。

こんなことでこのトラブルが解消するとは思えないけど、ま、地道にやっていくしかないよね。