- PR -

qmail+vpopmail で受信ができません。

投稿者投稿内容
anights
ぬし
会議室デビュー日: 2003/05/22
投稿数: 277
お住まい・勤務地: 東京
投稿日時: 2004-12-14 18:13
log 2では、success: did_0+0+1 とあるのでプログラムに渡されていることが
分かります。多分、vdelivermailに渡したのですかねぇ。

log 3では、success: did_0+1+0/qp_2651/とありますので
forwardが行われそのそのforward処理先のキューIDが
qp_2651であることが分かります。

他はまあ、問題ないかと。

log 2が一番手がかりになるかと思うのですが
vdelivermailに渡されてしまったとするとqmail側のログからは
もう動作を追えないと思います。successしちゃってますし。。。
タイムスタンプも問題ないようですからvdelivermailに渡すまでの
処理では問題ないかもしれません。

だとするとvdelivermailなのか?ということになりますが微妙。。。

ログ上でsuccessしてからメールボックスに反映されるまでの間に
vdelivermailとかのプロセスがずーっといるならアタリ!かも。

ちなみに、キューを直ちに配送させるのは
qmail-sendにALRMシグナルを投げてやります。
http://man.qmail.jp/jman8/qmail-send.html

あれ?キューに残っているなら話がまた違うジャン。。。

qmail-qstatとか、qmail-qreadの結果はどうなんでしょう?


[ メッセージ編集済み 編集者: anights 編集日時 2004-12-14 18:19 ]
RUHAKO
常連さん
会議室デビュー日: 2004/12/11
投稿数: 38
投稿日時: 2004-12-14 20:30
anightsさま

まず、qmail-qreadのコマンドを使用してみたところ
# /var/qmail/bin/qmail-qread
#
と何も返答を得る事はできませんでした。

次にqmail-statを行ったところ、

# /var/qmail/bin/qmail-qstat
messages in queue: 2
messages in queue but not yet preprocessed: 2

のようにqueueの中に未配信メールが溜まってることが確認できました。

queueにALRMシグナルを送信する為に
以下のコマンドを叩いてみた結果、
(1767はqmail-sendのPID)

# kill -ALRM 1767
# /var/qmail/bin/qmail-qstat
messages in queue: 2
messages in queue but not yet preprocessed: 2

となり、queueは未配信のままでした。
またqmail-lspawnコマンドを行ってみると
# /var/qmail/bin/qmail-lspawn
# /var/qmail/bin/qmail-qstat
messages in queue: 2
messages in queue but not yet preprocessed: 2

と、やはり変化はありませんでした。
しかし、qmail-sendのプロセスを強制的にkill(プロセスの再起動)をすると
# kill 1767
# /var/qmail/bin/qmail-qstat
messages in queue: 0
messages in queue but not yet preprocessed: 0

と無事にメールは配信されておりました。

qmail-lspawnは、qmail-sendがlocal受信者宛への
配送を行うためのプロセスという事ですので
このプロセスコマンドを行っても、mailboxに配信されない
ということは、このqmail-lspawn近辺に問題があるような気にも
なってきました・・・

Webで、情報を収集しているうちに
http://www.tcp-ip.or.jp/~ikken/intra/qmail.txt
上記の場所をたまたま通りがかり読んでいましたら、

* メンテナンスのヒント

$ /var/qmail/bin/qmail-qstat
messages in queue: 1
messages in queue but not yet preprocessed: 1

$ cd /var/qmail<<<<<<<<<<<<<<<<<< qmail のメ−ルキュ−にメ−ルが溜まっている状態。
$ /com/lst -l queue<<<<<<<<<<<<<< Apollo でコンパイルした qmail は、qmailを毎度起動しないとメ−ルを出さないので、メ−ルがたまっている様子が分かったのだ。
(dir) 4 queue/bounce
(dir) 4 queue/info/0
|
(file) 4 queue/intd/992696449
(file) 4 queue/mess/4/992696449
(file) 4 queue/todo/992696449


という内容を見つけ、「コンパイルで何かミスでもしてるのかもも;」
という気にも少しなってきてしまいました…。







[ メッセージ編集済み 編集者: RUHAKO 編集日時 2004-12-15 04:06 ]
anights
ぬし
会議室デビュー日: 2003/05/22
投稿数: 277
お住まい・勤務地: 東京
投稿日時: 2004-12-14 22:53
前言撤回

qmail-queueから、qmail-sendへの連携がうまくいってないかも。

このスレッドあたり。
http://sanguine.jp/pipermail/squirrelmail-users/2003-September/000937.html

そんなわけで/var/qmail/queue/lock/triggerとかは大丈夫ですか?

処理の内容的には、↓の 7.その他にあります。
http://man.qmail.jp/jmisc/internals.html

でこの連携に失敗していたとしてもqmail-sendは、
25分間隔?とかで/var/qmail/queue/todo/をチェックしているので
そのチェックにひっかかればqmail-sendに引き渡されます。

qmail-qstatの結果からするとtodo/のキューにも残っているので
かなりイイ線行っていると思うのですが。
RUHAKO
常連さん
会議室デビュー日: 2004/12/11
投稿数: 38
投稿日時: 2004-12-15 00:28
anights様

正常に動作しました☆


本当に本当にありがとうございました〜<(_ _*)>



先ほどの、URLをおっていくと、
やはり/var/qmail/queue/lock/triggerに問題があり
同じような現象がおきていた前例があるという記事がありました。
triggerのファイルが所定の場所にないと、
qmail-sendの動作に20分程の遅延が遅れるというものでした。
そして、付け加えとして
tarなどを使用して、/varディスクのバックアップなどを行った場合
部分的にアクセス権等がうまく反映されない事があるとの事です。

実は、私が今設定しているサーバは、
一度、必要なディレクトリ(/var含む)を
バックアップコピーしてあったものを、
現在のディスクに上書きした、サーバだったのです。
/var/qmail/queue/lock/ の配下をlsで見てみると
triggerというファイルがありました。

# pwd
/var/qmail/queue/lock
# ls -l
total 4
-rw------- 1 pop vida 0 Dec 9 23:06 sendmutex
-rw-r--r-- 1 qmails vida 1024 Dec 14 22:08 tcpto
prw------- 1 pop vida 0 Dec 11 20:18 trigger

アクセス権に外部よりの使用権利は一切ない状態です。

# chmod 722 trigger
# ls -l
total 4
-rw------- 1 pop vida 0 Dec 9 23:06 sendmutex
-rw-r--r-- 1 qmails vida 1024 Dec 15 00:05 tcpto
prwx-w--w- 1 pop vida 0 Dec 15 00:12 trigger

上記のように、外部よりの書き込み権を足してあげたところ
qmail-sendは正常に動作するようになりました。

(※chmodを744の”prwxr--r--”でtriggerを設定した場合
qmail-sendの動作は遅いままだったので、書き込み権が必要なようです。)


--
※編集後記

もう一度リンク先をよく読んでみたところ
プロセスは書き込みができるか確認しにtriggerを”読み”に行くという事です。
オーナーに対する実行権は実際には必要なく、

# chmod 644 trigger
# ls -l
total 4
-rw------- 1 pop vida 0 Dec 9 23:06 sendmutex
-rw-r--r-- 1 qmails vida 1024 Dec 15 00:05 tcpto
prw-r--r-- 1 pop vida 0 Dec 15 04:00 trigger

と644のアクセス権で問題ないという事です。
(よく考えたらそうですね・・^^;

--

多分、サーバーをすべて以前のバックアップした環境に
入れ替える時点で、triggerファイルのアクセス権に
変更が起こってしまったんだと…思います。


本当に、みなさんありがとうございました。
特にanightsさん、感謝しております。
お疲れ様でした。




[ メッセージ編集済み 編集者: RUHAKO 編集日時 2004-12-15 04:35 ]

スキルアップ/キャリアアップ(JOB@IT)