こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

解決済みの質問

MAILサーバが応答しなくなって困っています。

外部公開をしているメールサーバから応答がなくなりました。
その時点で私の知る限りでは、強制再起動しか打つ手がなく強制再起動を行いました。
(マジックSysRqキーを使用し、[Alt]+[SysRq]+[s]⇒[u]⇒[b]で再起動しました。)
環境と現象は以下のとおりです。


[環境]
 OS:CentOS release 4.5 (Final)
 kernel:2.6.9-42.0.3.EL
 RAID:Software RAID1
 主なDemon:
    ・bind-9.2.4-24.EL4 (外部向け)
    ・sendmail-8.13.1-3.2.el4 (SMTP/SMTPS) (外部向け)
    ・dovecot-0.99.11-8.EL4 (POP3/POP3S/IMAPS) (内部向け)
   ※ clam-milterとspamass-milterを導入し、ウィルス/スパムメール対策中です。

[現象]
 02:35頃 POP3の応答がなくなる
 09:30頃 サーバの応答がないことに気がつく
 09:50頃 PINGによる疎通確認 ⇒ Windows端末で実施し、応答がありました。
     SSH接続 ⇒ ID/PASS入力後、反応なし。
     コンソールログイン ⇒ ID/PASS入力後、反応なし。
 10:05頃 マジックSysRqキーによる強制再起動
     再起動後、MAILとDNSのサービス等を確認

 その後ログを確認
 [messages]
  02:00:57 hostname clamd[9214]: Reading databases from /var/clamav
  02:02:39 hostname clamd[9214]: Database correctly reloaded (235710 signatures)
  02:13:25 hostname clamd[9214]: SelfCheck: Database status OK.
  02:34:01 hostname named[2434]: lame server resolving 'XXX.XXX.XXX.XXX.in-addr.arpa' (in 'XXX.XXX.XXX.in-addr.arpa'?):XXX.XXX.XXX.XXX#53
  02:33:58 hostname named[2434]: client XXX.XXX.XXX.XXX#3143: updating zone 'mydomain.com/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
  02:33:58 hostname named[2434]: client XXX.XXX.XXX.XXX#3146: update 'mydomain.com/IN' denied
  10:06:36 hostname syslogd 1.4.1: restart.

 [maillog]
  02:33:03 hostname pop3-login: Login: user1 [YYY.YYY.YYY.YY1]
  02:33:09 hostname pop3-login: Disconnected [ZZZ.ZZZ.ZZZ.ZZZ]
  02:33:29 hostname sendmail[27371]: l5THXT9t027371: [ZZZ.ZZZ.ZZZ.ZZZ] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
  02:34:00 hostname pop3-login: Disconnected [ZZZ.ZZZ.ZZZ.ZZZ]
  02:33:59 hostname pop3-login: Login: user2 [YYY.YYY.YYY.YY2]
  02:33:59 hostname pop3-login: Login: user3 [YYY.YYY.YYY.YY3]
  02:33:58 hostname pop3-login: Login: user1 [YYY.YYY.YYY.YY1]
  02:34:01 hostname sendmail[27394]: l5THY14p027394: ppp-XXX-XXX.XX-XXX.iol.it [XXX.XX.XXX.XXX] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
  02:33:58 hostname sendmail[27402]: STARTTLS=server, relay=[ZZZ.ZZZ.ZZZ.ZZZ], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
  02:34:01 hostname sendmail[27419]: ruleset=check_relay, arg1=[XXX.XXX.XXX.XXX], arg2=127.0.0.4, relay=[XXX.XXX.XXX.XXX], reject=550 5.7.1 Rejected: XXX.XXX.XXX.XXX listed at all.rbl.jp
  10:06:43 hostname dovecot: Dovecot starting up

 [cron]
  02:01:01 hostname crond[26912]: (root) CMD (run-parts /etc/cron.hourly)
  02:10:01 hostname crond[27069]: (root) CMD (/usr/lib/sa/sa1 1 1)
  02:20:01 hostname crond[27236]: (root) CMD (/usr/lib/sa/sa1 1 1)
  02:30:01 hostname crond[27344]: (root) CMD (/usr/lib/sa/sa1 1 1)
  10:06:57 hostname crond[2868]: (CRON) STARTUP (V5.0)

 上記のとおり、サービスが応答しなくなってから再起動までログには何も記録されていません。

※ 今回はじめて発生した現象です。

原因も対策方法もわからず困っています。

この現象は、
 ・外部からの攻撃が原因なのでしょうか?
 ・OSまたはDEMONのバグ等なのでしょうか?

この現象にどのような対策を講じればいいでしょうか?


何か情報をお持ちの方がおられましたら、教えていただけないでしょうか?

投稿日時 - 2007-07-02 13:24:26

QNo.3133106

すぐに回答ほしいです

質問者が選んだベストアンサー

saは取得していますか?
取得していれば、パフォーマンスの確認は可能でしょう。

アタック云々に関してですが、どのようなサービスを提供しているかにもよりますが
/var/log/secureを確認してみてください。
また。FireWallのログを確認する事が可能であれば
その前後におかしな通信が発生していないかを確認してみるのも手です。

ログに関しても、もっと前から確認するべきです。
特に複合的な要因の場合には、前後には何も書かれていないかもしれません。

cat /var/log/message |grep error|grep warn などとして
確認を行なって見て下さい。
また、確認要件としては、dmesgも必要になるでしょう。

ログから原因がつかめない場合には
次回発生した場合に少しでも有用な情報を残すようにしておくべきです。

1)監視ツールによる監視
2)ホスト上での定期的なステータス収集
  cronで、1分毎にvmstat、tcpstat(恐らくインストールされていないでしょう)。netstat psの結果をファイルに残す など。
  #注意:放置しておくと容量が増えるので何かしらの対処を施しましょう

調査は状況によって変わりますし、かなり多方面からの調査が必要になると思われます。
  

投稿日時 - 2007-07-02 13:51:11

お礼

早々にご回答いただきありがとうございます。

> saは取得していますか?
残念ながら取得していませんでした。
これを機に取得を行います。

ちなみに、NET-SNMPを導入し別サーバのMRTGで収集していますが、
CPU使用率などは特に目立った変化はありませんでした。


> アタック云々に関してですが、どのようなサービスを提供しているかにもよりますが
> /var/log/secureを確認してみてください。
数日前までさかのぼりましたが、
管理者としてSSH接続したログしかないようです。
(ローカルのIPアドレスが記録されていました。)

> また。FireWallのログを確認する事が可能であれば
> その前後におかしな通信が発生していないかを確認してみるのも手です。
FireWallのログも確認しましたが、
前後におかしな通信は発生していませんでした。

> cat /var/log/message |grep error|grep warn などとして
> 確認を行なって見て下さい。
> また、確認要件としては、dmesgも必要になるでしょう。
こちらもおかしな情報は記録されていないように思えます。


> ログから原因がつかめない場合には
> 次回発生した場合に少しでも有用な情報を残すようにしておくべきです。

ご回答いただいたように、
次回発生に備えて有用な情報を採取できるようにスクリプトを仕込んでおきます。

取り急ぎ、お礼まで。

投稿日時 - 2007-07-02 15:28:40

ANo.1

このQ&Aは役に立ちましたか?

1人が「このQ&Aが役に立った」と投票しています

回答(2)

ANo.2

SNMPでの異常が無いとの事ですが
再起動を行う直前まで、情報は取れていましたか?

構成上、怪しいと思われる部分は
SoftwareRaidじゃないでしょうか?
あまり良い話は聞きませんし、技術屋さんは結構いやがると思います。

ログに残っていないとの事なので、最後の頼みの綱は
CoreDumpでしょうか。CoreDumpは残してますか?
(解析にはそれなりの知識と、かなりの時間を費やします)

システムの不具合となると、クラッシュが考えられます
もしもシステムを止める事が可能であれば、CPUチェックや
メモリチェック、HDDのチェックも行なってみるべきではないでしょうか?
(解決に繋がるかどうかは不明です)

投稿日時 - 2007-07-02 19:46:32

補足

> SNMPでの異常が無いとの事ですが
> 再起動を行う直前まで、情報は取れていましたか?

確認不足でした、
6/20にモジュールのアップデートを行ってたのですが、
それ以降、MRTGにて情報を収集できていませんでした。
こちらも原因のひとつとして疑うべきでしょうか?

> 構成上、怪しいと思われる部分は
> SoftwareRaidじゃないでしょうか?
> あまり良い話は聞きませんし、技術屋さんは結構いやがると思います。
私も、SoftwareRaidにかなり不信感があります。
別のサーバでも、同OSでSoftwareRaidを構築していますが、
こちらでも同様の現象が発生したことが数度あります。
(PING応答有り、SSHログイン不可能・・・)



> ログに残っていないとの事なので、最後の頼みの綱は
> CoreDumpでしょうか。CoreDumpは残してますか?
> (解析にはそれなりの知識と、かなりの時間を費やします)
CoreDumpの出力は行っていませんでした。
(/proc/sys/kernel/core_pattern)
CoreDumpを解析できるだけの知識がないのが正直なところです。


> システムの不具合となると、クラッシュが考えられます
> もしもシステムを止める事が可能であれば、CPUチェックや
> メモリチェック、HDDのチェックも行なってみるべきではないでしょうか?
> (解決に繋がるかどうかは不明です)
先の、SoftwareRaidの件もありますし、
一度構成を再検討する必要があるのかも知れません。

追記>
 前回頂いた回答に、補足ですべきでした。
 不慣れで申し訳ありませんでした。

投稿日時 - 2007-07-03 10:12:04

あなたにオススメの質問