- - PR -
送受信が突然できなくなる？！(qmail)
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-05-02 12:48
お世話になっております。
皆様からご指導いただいた今回の件のご報告と新しい問題が発生しました。 まず、maillogを見たところ、 deferral:CNAME_LOOKUP_failed_temporarily.(#4.4.3) とあった為、過去ログを検索し、下記の処置を施しました。 １、mail.abcde.co.jp. IN CNAME ns.abcde.co.jp. としていたところを、 mail.abcde.co.jp. IN A xxx.xxx.xxx.xxx と変更。 ２、resolv.confに記述がなかったので下記内容を追記 domain abcde.co.jp nameserver 0.0.0.0 nameserver xxx.xxx.xxx.xxx(ISPのDNSのアドレス) 再起動後、メールの送受信が可能となり、CNAMEのエラーメッセージは出なくなりました。 その後、６時間程してまたメールの送受信が行われない現象が発生。 夜中ですが、会社に行きログを見たところ、特に送信してないメッセージがない。 いろいろページをみて、キューの再送信を行おうということで、 １、qmail-qstatで６０通がqueueにあるのを確認。 ２、qmail-tcpokと打ち込み ３、ps -ax | grep qmail-sendでPIDを確認 ４、kill -s ALRM [PID]を行うも何も起こらない。 そこで、ps -ax | grep qmailとするとqmail-remoteが３０個くらいありました。 片っ端からKILLして行き、上記の作業を繰り返している内に数十通は 再送信されたのですが、最後２７通だけどうしても送れない。 ただこの状態になればメールの送受信が行えるようにはなったのですが、 また起こるのが容易に想像できたので、また代替機に変更して帰ってきました。 そもそも、qmail-remoteってそんなに沢山プロセス上に表示されるのでしょうか？ queueにあるメールは、手動で送信かなんかできないまずいんですよね・・・ 今は、送信者と受信者と日時からユーザーに連絡して、再度送信お願いしようと 考えています。２７通は消さないと多分また同じ事になるでしょうし。 これもDNS廻りに原因があるのでしょうか？ どうか、ご教授お願いします。 （gooにも投稿してます。削除ができないのでマルチキャストになってます。お許しください。） | ||||||||
|
投稿日時: 2005-05-02 13:15
こんにちは。GW 中のトラブルシューティング、お疲れ様です。
とりあえずのトラブルの原因は、DNS が絡んでいたようですね。 今後とも、DNS 関連で何かあるかもしれないので、暫くは注意が必要そうですね。 ( DNS 通信をダンプしつづけるとか、DNS クエリーのログを詳細に取って置くとか… )
DNS もしくは、相手サーバの問題で、送信待ちのプロセスが残っているのでしょうね。 通常は瞬時に完了するため意識しないですが、メールの送信 1 通につき、qmail-remote 1 プロセスが対応します。 そのため、送信待ちが発生すると、未完了のプロセスがたまりますし、concurrency-remote で設定した上限一杯まで行くと、以降のメール送信がストップしてしまいます。 送信に関わる通信を監視/解析するとともに、qmail-remote の各タイムアウト値も見直すのはいかがでしょうか? 詳細は、man qmail-remoteをどうぞ。 後は…、相手サーバからの ident 要求や、送信元ドメイン名チェック(逆引きや paranoid とか)で待ちができてしまっている、ってこともありそうな。これは裏が取り辛いでしょうが。 ともあれ、問題のあるメールの送信先の共通点が見つかれば、解決にかなり近づくように思います。 以上、ご参考まで。 ※ 場合によっては smtproutes を悪用して、振り先のメールサーバを、(問題のアドレスへの送信に関しては)固定してしまう、という手もあるかも。かなり注意が必要だと思いますが。 [ メッセージ編集済み 編集者: angel 編集日時 2005-05-02 13:30 ] | ||||||||
|
投稿日時: 2005-05-02 13:59
こんにちは。
queueに溜まっているメールというのは、 1. 内部から外部のメール 2. 外部から内部のメール 3. 両方 この中のどれだったのでしょうか。 また、それらのメールに何か特徴というか統一性はありましたか？ 例えば宛先ドメイン名が全て同じであるとか、またはある程度絞れるとか。 現状は代替機にて運用されてるとのことですが、全く同じ構成で作ってるなら 同じ事象が起こる可能性もあるかもしれませんね。 何はともあれもう少し事象を絞り込むことができれば解決への道が開けるかも 知れませんね。がんばってください。 ----- kernel再構築してECNが有効になっちゃったって可能性をちらっと思いついたのですが そういったことはされてないですよね？ | ||||||||
|
投稿日時: 2005-05-02 21:41
angel様、綾瀬様ありがとうございます。
まず、送信できなかった２７通の内の大半が同一ドメインでした。 ですが、このドメインは重要取引先に近く、前からずっと送信できていました。 （できてなければ、とっくにクレームの嵐でしょうから） そのドメインのメールサーバーが何か行っている（何か問題が発生している）なら 再送信できないのもうなづけますが、大きい企業なので多分こっちに問題あるのかな？と。 ただ、maillogでは、deferral:Connected_to_xxx.xxx.xxx.xxx_but_connection_died.(#4.4.2)が、そのドメインに対して非常に多く見受けられます。 あと、送信している気配もないかな？それに、deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/もありますね。 また、綾瀬様の指摘の、queueにたまっているのは、外部への送信メールです。 ECN?ってのは、まったく意味が分からない上に再構築なんてできません。＾＾； また、ログの方を調べていると１件だけCNAMEのエラーが出ていました。 ただ、DNSの方には現在CNAMEは一切記述していません。 でも、推測するに、DNS廻りの問題がまだあるのかな？と。 相当混乱してきました・・・まずは中間ご報告まで。 | ||||||||
|
投稿日時: 2005-05-02 23:47
こんばんは。
いやいやいや。そうとも言えないのが怖いところ。
これを素直に解釈すると、TCP 接続ができない(後者)、もしくは TCPのハンドシェークが完了したがサーバから応答が無い(前者)、となるので、原因は向こうにあるというのが第一感なんですよね。 SMTP 通信の場合、サーバからの第一声が来ないと、クライアント(qmail-remote)側も動きようが無いわけで。 ここら辺は SMTP通信の内容をキャプチャすれば裏が取れると思います。後、自分側のファイアウォールやロードバランサが間にあれば、そこでの設定や通信内容の解析も必要でしょうか。 さて…、この問題が一時的(相手方がメンテナンス中や高負荷状態等)なら待つしかないですが、延々続くようだと政治的に動かないといけないかも、ですね。 ※逆にそうなれば、上司に負荷をおすそ分けできて楽になれるのでしょうか？ 頑張って下さい。 | ||||||||
|
投稿日時: 2005-05-03 00:08
こんにちは。
queueにあるのが外向けのメールってことは、内向けのメールが届かないというのは とりあえず解決したんですかね？ 送れないところが絞れるということは、ネットワーク的な問題もありそうですね。 相手が大きかろうが小さかろうが、いままで出来ていたものが出来なくなったと 言うことはどちらかが何らかの設定変更をした可能性が高い気がします。 とりあえずtelnetなどで相手のメールサーバのTCP25につないで応答あるどうかの 確認はとれますか？ あと、この事象が出る前に回線の変更かF/Wの設定変更したりはしていませんか？ (相手が変更したかとかも判るとまた原因突き止めるのが早いのですが) もし変更したのであればMTUとか一度小さくして試してみるなども やってみてはいかがでしょうか。 ECNはそのまま「Linux ECN」でgoogleさん行くとすぐに出てきますが、 RedHat9の初期値がどうなのか私は知らないので何とも言えません。 (OFFにしてるディストリビューションが多そうなのであまり関係ないかも) 私はネットワークの観点からしかお話できないので今言えるのはこれくらいですかね。 他に気になることがある方々、よろしくお願いします。 | ||||||||
|
投稿日時: 2005-05-03 01:43
どのくらいを大きいと言っているか分かりませんが 企業の大きさとシステムの構えはイコールではないと思いますが。 私の経験からするとですけどね。
エラー文言の「CNAME」はDNSでいう「CNAME」じゃありませんが。 ただのCanonicalの意味で使っているんだと思いますよ。 | ||||||||
|
投稿日時: 2005-05-03 09:41
おはようございます。
皆様色々とありがとうございます。 先ほど、誰が誰にいつどのくらいのメールを送ろうとしてキューにはいったのか２７通調べてみました。 結果、半分が同じ人間で、ほぼ同じ時間に例のドメインへメール送信をしていました。 （TO:CCを含めると３０くらいはありました。） 相手側が短時間の間で同一ドメインからの問い合わせが来ると、メールを受信しないと （SPAMとみなしたりする）とありましたので、その可能性はあるかな？と。 再送信するときも同じタイミングで一斉にリクエストするので、何度やっても結果はいっしょ。としているうちに、qmail-remoteがいっぱいになって、次からのメールを送信できなくなる。 そこで、片っ端からqmail-remoteをKILLしていくと次のメールがqmail-remoteに入って送信されていく。 でも、例のドメインだけは拒否されていて、いつまでたっても送信できない。 そのうちqmail-remoteが上限いっぱいになって、また送受信できなくなる・・・ こういう場で馬鹿をさらけ出すのも恥ずかしいのですが、上記が原因でないかと 推測しました。ただ、全てを説明できる訳でもないのですが。 >とりあえずtelnetなどで相手のメールサーバのTCP25につないで応答あるどうかの >確認はとれますか？ やり方調べてやってみます。（できるかな？＾＾；；） あとは、キューに溜まったのを１つづつ送信指示していく方法も考えて行きます。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。