Today we experienced a mail delivery problem that has gotten us before. Basically, a machine not under our pervue had been sitting with a metric ****ton of cued messages for one person on our system. The administrator of this machine "fixed" the problem, and it's mail server happily began to deliver these into our system. Now, the MTA will accept bunches of message for someone, fork off MDA processes (procmail) to deliver to the local addresses, the MDA will wait for a lockfile to deliver the message, do it's thing, clear the lock file, etc. Of course, if you've got a TON of messages being delivered, there are problably the respective TON of procmail processes waiting for their lockfiles... After awhile, things begin to break down, as all of the available sendmail children processes are waiting for their respective MDA's to deliver messages to this one address... WAIT, what's that locking thing???
So, awhile ago, we switched to a message storage format similar to maildir, which doesn't require ANY file locking when delivering a message. But, you guessed it, procmail was utterly insisting on doing some locking. After some digging in the procmail code -- something not recommended to the squeemish -- I found that, while procmail supported maildir, there was no provision for NOT locking when the delivery target was a directory. Surprise, ok, there is now.
This should actually speed our mail delivery up substantially, now an expesive operation (locking) isn't part of the game.
Comments (2)
pxgvsmor akfc rgma zefoap wzof tzrksvpj zfbcuw
Posted by ncai izqlock | June 6, 2007 12:29 AM
Posted on June 6, 2007 00:29
pxgvsmor akfc rgma zefoap wzof tzrksvpj zfbcuw
Posted by ncai izqlock | June 6, 2007 12:30 AM
Posted on June 6, 2007 00:30