- Jonathan Nalley <[EMAIL PROTECTED]>:
| The interval of time at which the queue is processed seems quite
| long. A local to local delivery may take 45 minutes.
That is *definitely* wrong.
| Also I read that I could force the queue to run by sending a SIGALRM
| to qmail-send. When I do this the log file shows that the queue
| attempts to process messages destined for remote hosts, but it fails
| to process messages to be delivered locally.
Is it possible that some local deliveries are hanging, taking up all
the local delivery slots? Check the log for status messages. A
typical one looks like this: status: local 1/10 remote 1/20 which
means that one out of 10 local delivery slots is taken, etc.
| If I send a SIGALRM to qmail-lspawn all messages are processed. As
| a temporary fix I have been sending a SIGALRM to qmail-lspawn to
| force delivery.
Hmm. I don't see a signal handler for SIGALRM in the code, so I would
expect that to terminate qmail-lspawn and hence bring qmail-send
crashing down??
| I would like to know what causes the queue to be processed, does it
| normally run upon receipt of each new message?
Yes. See the end of the INTERNALS file, and check the permissions on
stuff in the lock/ subdirectory. "make check" does this for you. If
it reports any problems, stop qmail and run "make setup" to repair the
damage. (But a wrong permission on lock/trigger will typically only
cause a <25 minute delay, as that is how often qmail-send checks the
todo/ subdir in the absense of activity on lock/trigger.)
| Any advice for things to look for is greatly appreciated.
Other than the above, the only thing I can think of is to trace your
processes to see what they're up to. And you could tell us what OS
you're on. Maybe there is an OS bug or gotcha that someone here knows
about.
- Harald
