Dealing with Orphaned queue files

[Jim Holland]

On Fri, 22 Sep 2006, James Gray wrote:

> On 22/09/2006, at 12:50 PM, Errol Neal wrote:
> 
> > I'm running mailscanner-4.54.6-1 on centos. Sendmail 8.13.6
> > I'm seeing a lot of orphaned queue files in /var/spool/mqueue.in. How
> > can I prevent from happening?
> 
> Despite having the correct lock type in my sendmail boxes, I still  
> seem to accumulate a few of these from time to time.  Usually when  
> the system is under heavy load.  My solution was simply to write a  
> script that hosed any queue files older than 5 days.  Less than that  
> is dangerous as sendmail usually retries messages for four days - if  
> you clean out queue files that are <5 days, you risk loosing  
> legitimate messages.
> 
> Not a "clean" solution, but functional enough for more purposes.

If the file has not been modified for more than an hour then it is
unlikely that the sending server will still have that connection active
(with sendmail the default data timeout for sending is 1 hour, for
example), and even if it is the chances of it being completed successfully
are remote.  So what I do with any queue file more than an hour old is
first to check if there is an associated sendmail process, and if there
is, kill that, then delete the file.  That should be perfectly safe.

There is one exception that I can think of, and that is when some 
braindead system (such as Yahoo, Gmail etc) does not use the ESMTP SIZE 
extension, so with low bandwidth like ours it could take a couple of hours 
to send us one of their 15 MB files while at our end we will just see an 
apparently dead queue file that hits the maximum size limit we have set 
(1.5 MB) and then never gets larger and so doesn't get modified.  Killing 
the process and deleting the file would just cause them to resend, 
starting the whole problem all over again.  So for the moment I don't 
automate this - in such cases I first blacklist the server, then kill the 
file, then remove the blacklisting once I see that the server has made a 
further connection attempt and been rejected.  Very annoying, and a 
problem that I can't see a solution to for the moment.

Regards

Jim Holland
System Administrator
MANGO - Zimbabwe's non-profit e-mail service