Hello,
I am running qmail-1.03 with qmail-ldap-20011001a. I ran a big fat load test, and loaded up my queue, over about 3 hours, with 30,000 messages (had around 20k deliveries over that time, I reckon). Over the next 3 or 4 hours, qmail obediently continued to deliver mail until the queue was empty. Almost.
Let me clarify that this is on a RedHat7.2 system, on a Dell PowerEdge 1650 (some 1Ghz proc, some 2Gb RAM). Let me also clarify that these messages were spawned on another machine on the same 100 base T network (the other machine was running a webmail client being excercised by a web load tester). Let me further clarify that the queue for these messages, running on the qmail machine, was an NFS share (a good one). Finally, these messages were not remote: all were scheduled for delivery to users local to that qmail machine, and the logs show that all messages processed were recognized as such.
The oddness is that at the very end of the test, qmailctl stat showed the queue to be stuck at two messages. In reviewing the queue by hand, there were two messages, one in mess/13 and one in mess/21. The file dates on these files showed them to have been written early on in the test, during the first hour or so.
But, qmail-send/qmail-lspawn/qmail-local did *not* recognize these as being scheduled for local delivery: they understood the queue to be empty.
My questions:
(1) given no hung processes (qmail would continue to operate normally beyond this point; restarting qmail, restarting the server, neither had any effect as the queue size remained at 2), what could cause this sort of a problem of undeliverable, "invisible" messages?
(2) I thought these messages should have been scooted over to the local/## directory instead of staying in mess/##. Could someone give me some tips at understanding qmail's queue/scheduling mechanism?
Thanks in advance,
-EdA
[EMAIL PROTECTED]
