Matthew Seaman <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 18, 2004 at 09:57:22AM -0400, Bill Moran wrote:
> > Charles Swiger <[EMAIL PROTECTED]> wrote:
> > 
> > > On Jun 17, 2004, at 2:39 PM, Bill Moran wrote:
> > > > What does it mean when I have a lot of files in /var/spool/mqueue?  I 
> > > > don't
> > > > really understand what that particular queue is for.
> > > 
> > > That is the queue of unsent messages which sendmail will periodicly 
> > > attempt to resend (every four hours, by default).  You can try to flush 
> > > them via "sendmail -v -q".
> > 
> > I appreciate the input, Chuck, but now I'm more confused.
> > 
> > When I did this, folks suddenly started receiving emails from two years ago.
> > I'm a bit confused as to _why_ sendmail would hang on to mails from years ago
> > without either delivering them or bouncing them?  Could the queue have been
> > corrupt?
> Sounds like you aren't running a sendmail process to flush the queue
> regularly.  Which means that any message that cannot be delivered
> immediately will be stuck into the /var/spool/mqueue directory and
> forgotten about.
> Look at /var/run/ -- the second line shows what command
> line sendmail was started with.  Typically it will be something like:
>     /usr/sbin/sendmail -L sm-mta -bd -q30m
> (You can't use ps(1) to extract this information, because sendmail is
> one of those programs that futzes with its argv[][] array as it runs)
> Unless you have a -qNNN flag in there somewhere, sendmail won't be
> processing any queued messages for you.  Set this using the
> 'sendmail_flags' variable in /etc/rc.conf if necessary, although the
> value I've shown is the default. The trailing bit '30m' is how
> frequently sendmail attempts to run the queue -- somewhere between 15m
> and 30m is best: don't be tempted to set it too short, or you'll not
> give any correspondents enough time to sort out any problems their end
> before you try re-sending.
> If you end up with a load of messages stuck in
> /var/spool/clientmqueue, you've got a similar problem with not running
> a MSP queue daemon.  The case is exactly analogous, except that the
> sendmail flags are in /var/spool/clientmqueue/ and should
> read:
>     /usr/sbin/sendmail -L sm-msp-queue -Ac -q30m
> and you need to set 'sendmail_msp_queue_flags' in /etc/rc.conf to
> override them.

Thanks a lot Matthew.

All these appear correct (exactly) with what you show.

It makes it all the more mystery why these messages are getting hung up.

I'm going to keep an eye on the server for a while and see if I can figure
anything out.

Bill Moran
Potential Technologies
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to