On Thu, May 07, 2009 at 10:16:51AM +0530, ram wrote:
> > The "pickup" process is not responsible for moving mail out of the
> > "incoming" queue. If mail is stuck in "maildrop", then debug "pickup".
> >
> > http://www.postfix.org/QSHAPE_README.html#queues
>
> Sorry, I had not fully read the architecture. If mails are coming from
> a remote host , the go first into incoming and then put into active.
>
> In my case the incoming directory keeps increasing in size( and number
> of files) and the active directory is empty
>
> Why are the mails not put into active ?
Well, I did spend a good chunk of time writing the document:
http://www.postfix.org/QSHAPE_README.html#incoming
The queue manager scans the incoming queue bringing any new mail into
the "active" queue if the active queue resource limits have not been
exceeded. By default, the active queue accommodates at most 20000
messages. Once the active queue message limit is reached, the queue
manager stops scanning the incoming (and deferred, see below) queue.
Under normal conditions the incoming queue is nearly empty (has
only mode 0600 files), with the queue manager able to import new
messages into the active queue as soon as they become available.
The incoming queue grows when the message input rate spikes above
the rate at which the queue manager can import messages into the
active queue. The main factors slowing down the queue manager are
disk I/O and lookup queries to the trivial-rewrite service. If
the queue manager is routinely not keeping up, consider not using
"slow" lookup services (MySQL, LDAP, ...) for transport lookups
or speeding up the hosts that provide the lookup service. If the
problem is I/O starvation, consider striping the queue over more
disks, faster controllers with a battery write cache, or other
hardware improvements. At the very least, make sure that the queue
directory is mounted with the "noatime" option if applicable to
the underlying filesystem.
If the files are mode 0700, and the active queue is not full, your queue
manager is not doing its job at all, or is totally starved of disk I/O
or is stuck waiting for trivial-rewrite to perform table lookups.
One possiblity not mentioned in QSHAPE_README, is qmgr(8) DoS via a slow
syslogd(8) on a Linux system with an incorrectly defined "mail" facility
log file (uses /path not -/path). This would probably be the best guess
here.
http://www.postfix.org/BASIC_CONFIGURATION_README.html#syslog_howto
http://www.postfix.org/LINUX_README.html
It is fundamentally the same as the disk-starvation, only the cause is
more indirect, because syslogd is starved for disk, and qmgr is blocked
waiting for syslogd. As with direct disk I/O startvation, a single qmgr(8)
is competing against lots of smtpd(8) and cleanup(8) processes, so can't
possibly keep up.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
