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?

Steven Oxley
  • 263
  • 1
  • 2
  • 9
  • 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... – Steven Oxley Jun 04 '10 at 17:41

5 Answers5

30

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.

DBrown
  • 113
  • 5
weeheavy
  • 4,039
  • 1
  • 27
  • 41
  • He said he had already done this, but messages re-appeared... – Massimo Jun 09 '10 at 13:33
  • 1
    But without stopping sendmail first, that's the point. – weeheavy Jun 09 '10 at 13:40
  • Well, it appears that you may have struck upon the step that I missed. – Steven Oxley Jun 10 '10 at 17:06
  • On Fedora 19, I see /var/spool/clientmqueue (as well as /var/spool/mqueue) – TomG Dec 07 '13 at 16:23
  • For some reason even with sudo this wouldn't work for me (it would say `no matches found`). So I `chmod`ed the folders to `777` and was then able to delete the contents. – Sridhar Sarnobat May 02 '14 at 00:43
  • If you're a sissy like me (and you should be), do `mv /var/spool/mqueue/* /some/other/location` instead of `rm`. – Felix Frank Dec 23 '14 at 10:11
  • @xebeche answer below should be taken in consideration: using the `qtool`, made to *manipulate sendmail queues* utility seems a good idea. – smonff Sep 07 '15 at 12:53
  • I'd also vote against using the `rm` command; at least as long as sendmail is running (and it's a general mail server). Otherwise new messages being queued (maybe due to high load) could be removed by mistake. – U. Windl Mar 08 '18 at 13:59
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 <vfn-l-bounces+so=example.com@fam.tuwi
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <so@example.com>
oBAEMuV8000429     1058 Fri Dec 10 15:22 <vfn-l-bounces+sby=example.com@fam.tuw
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <so@example.com>

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 :-)

xebeche
  • 341
  • 3
  • 11
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.

Massimo
  • 68,714
  • 56
  • 196
  • 319
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
Shu Hikari
  • 131
  • 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. – Felix Frank Dec 23 '14 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 '15 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. – Felix Frank Jul 01 '15 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 '15 at 12:38