21

I have a pretty annoying problem here. I have been testing an application and have created some test e-mails to bogus e-mail addresses (not to mention that my server isn't really set up to send e-mail anyway). Of course, sendmail is not able to send these messages and they have been getting stuck in the sendmail queue. I want to manually delete the messages that have been building up in the queue instead of waiting the 5 days that sendmail usually takes to stop retrying.

I am using Ubuntu 10.04 and /var/spool/mqueue/ is the directory in which every how-to I have read says the e-mails that are queued up are kept. When I delete the files in this directory, sendmail stops trying to process the e-mails until what appears to be a cron script runs and re-populates this directory with the messages I don't want sent. Here are some lines from my syslog:

Jun  2 17:35:19 sajo-laptop sm-mta[9367]: o530SlbK009365: to=, ctladdr= (33/33), delay=00:06:27, xdelay=00:06:22, mailer=esmtp, pri=120418, relay=e.mx.mail.yahoo.com. [67.195.168.230], dsn=4.0.0, stat=Deferred: Connection timed out with e.mx.mail.yahoo.com.
Jun  2 17:35:48 sajo-laptop sm-mta[9149]: o4VHn3cw003597: to=, ctladdr= (33/33), delay=2+06:46:45, xdelay=00:34:12, mailer=esmtp, pri=3540649, relay=mx2.hotmail.com. [65.54.188.94], dsn=4.0.0, stat=Deferred: Connection timed out with mx2.hotmail.com.
Jun  2 17:39:02 sajo-laptop CRON[9510]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Jun  2 17:39:43 sajo-laptop sm-mta[9372]: o52LHK4s007585: to=, ctladdr= (33/33), delay=03:22:18, xdelay=00:06:28, mailer=esmtp, pri=1470404, relay=c.mx.mail.yahoo.com. [206.190.54.127], dsn=4.0.0, stat=Deferred: Connection timed out with c.mx.mail.yahoo.com.
Jun  2 17:39:50 sajo-laptop sm-mta[9149]: o51I8ieV004377: to=, ctladdr= (33/33), delay=1+06:31:06, xdelay=00:03:57, mailer=esmtp, pri=6601668, relay=alt4.gmail-smtp-in.l.google.com. [74.125.79.114], dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
Jun  2 17:40:01 sajo-laptop CRON[9523]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)

Does anyone know how I can get rid of these messages permanently? As a side note, I'd also like to know if there is a way to set up sendmail to "fake" sending e-mail. Is there?

1
  • Well, I still haven't found any solution to this problem. It definitely looks like it's some sort of cron script that is causing it to happen, but I can't figure out where it is storing the queued messages... Jun 4, 2010 at 17:41

5 Answers 5

30
+100

The messages that have been sent or are trying to be sent are stored in /var/spool/mqueue. Messages that Sendmail has not tried to queue yet can be found in /var/spool/mqueue-client.

So try this (I assume you want to get rid of all messages in the queue):

  • Stop sendmail
  • rm /var/spool/mqueue/*
  • If you want to remove messages in waiting, rm /var/spool/mqueue-client/*.
  • Start sendmail

This will clear our your queue folder(s) until the system receives another message. You can double check by running mailq (both queue folders), or sendmail -bp (only the queue folder).

NOTE: With most Linux distributions you can start/stop services with with service sendmail <start|stop|restart> or /etc/init.d/sendmail <start|stop|restart>. Both options have many other status flags which can be observed by typing in the command and service without the status flags.

9
  • He said he had already done this, but messages re-appeared...
    – Massimo
    Jun 9, 2010 at 13:33
  • 1
    But without stopping sendmail first, that's the point.
    – weeheavy
    Jun 9, 2010 at 13:40
  • Well, it appears that you may have struck upon the step that I missed. Jun 10, 2010 at 17:06
  • On Fedora 19, I see /var/spool/clientmqueue (as well as /var/spool/mqueue)
    – TomG
    Dec 7, 2013 at 16:23
  • For some reason even with sudo this wouldn't work for me (it would say no matches found). So I chmoded the folders to 777 and was then able to delete the contents. May 2, 2014 at 0:43
10

You will often find the suggestion to remove files from Sendmail's mqueue directory with for instance rm /var/spool/mqueue/* or worse (rm -rf etc.). IMHO, this is plain dangerous. It will work in many cases but I recommend to fasten your seat belts. Simply removing all files from mqueue might delete legitimate messages.

To stop Sendmail before removing queued messages is good advice especially if many messages need to be removed. However, if only a few messages are to be removed or if the queue is cleaned up on a regular basis e.g. by means of a cron job there is actually no need to stop Sendmail. In the worst case one of the messages will be re-queued which will almost certainly be removed when you try again.

On the contrary, stopping Sendmail (e.g. in Ubuntu with service sendmail stop) might not be sufficient. Even when stopped some (child) processes might still be running. One would have to wait until they finished (recommended) or kill them.

In order to safely remove messages from mqueue you need the messages' queue IDs. The IDs are shown in the log after "sm-mta[...]:". The IDs from your log excerpt are o530SlbK009365, o4VHn3cw003597, ... For each of the IDs 2 files are stored in mqueue, one starting with "qf", the other starting with "df".

mailq is generally used to list the queue's content. It shows the IDs in the first column. Furthermore, you should consult mailq's output because it also shows whether a message is active/currently being processed. E.g.

-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------
oBDDuKAB023946*    1058 Mon Dec 13 14:56 <[email protected]
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <[email protected]>
oBAEMuV8000429     1058 Fri Dec 10 15:22 <[email protected]
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <[email protected]>

In this example the message with ID oBDDuKAB023946 is currently being processed, shown by the appended asterisk. Other messages are safe to be removed. For example, in order to remove the message with ID oBAEMuV8000429 use

rm /var/spool/mqueue/{d,q}foBAEMuV8000429

A more versatile approach to remove queued messages is provided by Brandon Hutchinson in Deleting mail from the mail queue. Brandon also includes scripts to remove messages based on the domain part, email address etc.. Brandon's scripts are very helpful for regular cleanup or mass removal.

Nevertheless, even Brandon's scripts are not taking care of the messages' status. However, it's easy to add. Include at the beginning of his scripts

# Get current mailq status
my $mailq = `mailq`;

Then, at the beginning of the sub routine "wanted" add a check to skip active messages, e.g. with

# skip if file is currently processed by MTA
if ($mailq =~ /\n$queue_id\*/) {
   $debug && print "$queue_id is locked.\n";
   last;
}

HTH. And, remember to make backups :-)

4

I had this same problem and found that there were 2 folders with queued messages. The folder /var/spool/clientmqueue/ had messages that were ending up in /var/spool/mqueue/ if they failed to be delivered. Deleting the files from both folders were necessary to solve the problem.

rm -f /var/spool/clientmqueue/* rm -f /var/spool/mqueue/*

0

I don't think this is the work of a cron script, it's more likely to be an application issue, or something related to sendmail itself; anyway, to rule out any cron job doing this, you can just stop crond for a while and see if this keeps happening.

0

I managed to do this by using this bash script

for i in `sudo ls /var/spool/mqueue`
do
    sudo rm -rv `echo /var/spool/mqueue/$i`
done
4
  • So you open a subshell just to invoke echo and retrieve the output of said echo for use as a parameter to rm. Even ignoring the gratuitous forks of sudo and rm, this subshelling is plain wasteful. Dec 23, 2014 at 10:04
  • Well, if you have a more 'acceptable' solution, it wont be a waste of time to explain your solution instead of just showing how useless a comment can be. Thanks in advance
    – Shu Hikari
    Jun 30, 2015 at 20:32
  • 2
    Sorry if this came across offensive and arrogant. A more economic approach would be sudo find /var/spool/mqueue -maxdepth 1 -delete. I did find it important to point out what is problematic with your script in particular. Apologies for the lack of tact. Jul 1, 2015 at 13:59
  • 2
    Yep, but now you explained your point and I completely understood it. And apologies accepted, don't worry. Thanks :D
    – Shu Hikari
    Jul 17, 2015 at 12:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .