Help in clearing out /var/spool/mqueue

[NDO]

Hi All!

Please can you help me in understand why this directory is filling up and also cleaning out this directory, because is causing /var to get 100% full.

F.R.

[Viktor Balogh]

Hello,

this is for mail queueing. some of your users have got huge mails in their mailboxes...

If you want to free up some space in /var, you can commit old superseded patches like this:

# cleanup â c 1

After that you'll have time to sort the mail thing out..

Regards,
Viktor

[Matti_Kurkela]

As Viktor said, /var/spool/mqueue is the mail queue directory. If those mails were going to your local users, sendmail would quickly move them to /var/mail/ - so these mails are probably addressed to somewhere else.

Run "mailq | more" to see some basic address and subject information about each message in the queue.

If you can determine all the messages in the mail queue are junk or obsolete, you can delete the entire mail queue - just make sure the Sendmail daemon is stopped before doing that.

Procedure:
mailq | more
sh /sbin/init.d/sendmail stop
rm -f /var/spool/mqueue/*
sh /sbin/init.d/sendmail start #(if appropriate)

Some possible scenarios:

1.) You may have an old and forgotten cron job that runs rather frequently. It used to run without no errors at all, producing no output. But now some change has caused it to produce error messages, and the cron daemon is trying to mail those errors to the owner of the job (or whoever else has been configured to receive the errors from that cron job).

2.) If TCP port 25 of your system is reachable from the internet and your system allows mail relaying for anyone (known as "open relay"), a spammer might be exploiting your system. If your mailq output indicates that about >95% of the messages are for recipients outside your organization and subjects include "h3rbal v1agra" or are otherwise identifiable as junk mail, this is probably the case.

3.) If you have shut down your Sendmail daemon and the recipients in the mailq listing all seem legitimate, your site's mail server may have been unreachable.

Whenever you attempt to send mail from this system, the system makes _one_ attempt to deliver the mail to the destination immediately; if that attempt fails, the outgoing mail is placed into /var/spool/mqueue and the sendmail daemon is supposed to retry it until the retry time limit expires. But if your Sendmail daemon is disabled, nothing will take those delayed messages out of the queue - so the queue will keep accumulating forever, until the sysadmin notices something is wrong.

On HP-UX 11.23 and older, whenever you disable the Sendmail daemon, you should set up a periodic cron job that runs "sendmail -q" every 30 min or so; with this command, Sendmail will make one pass through the mail queue and will make attempts to deliver each message to their destination; or if the retry time limit has expired, it will delete the message from the queue and create a bounce message to the original sender.

On HP-UX 11.31, the procedure is different: if you don't want the system to receive email, but want to still send it, you should *not* completely disable the sendmail daemon; instead, you should set SENDMAIL_SENDONLY to 1 in /etc/rc.config.d/mailservs.

MK

[NDO]

Hi!

I am running 11.23, and this what I ve got when I run mailq:


p24KJkd10523 3368993 Fri Mar 4 22:21 MAILER-DAEMON
(alias database unavailable)
root
p24G7Cx06547 3367565 Fri Mar 4 18:07 root
(alias database unavailable)
bscsprod
p2682AU03088 20888578 Sun Mar 6 10:02 MAILER-DAEMON
(alias database unavailable)
root
p2682AV03088 21003301 Sun Mar 6 10:02 MAILER-DAEMON
(alias database unavailable)
root
p24LJuO11371 20886782 Fri Mar 4 23:24 MAILER-DAEMON
(alias database unavailable)
root
p24LJuP11371 21001505 Fri Mar 4 23:24 MAILER-DAEMON
(alias database unavailable)
root
p269QLL06416 378877167 Sun Mar 6 11:31 MAILER-DAEMON
(alias database unavailable)
root
p269QLM06416 378878968 Sun Mar 6 11:31 MAILER-DAEMON
(alias database unavailable)
root
----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient------------
p29C8wd02525 1544 Wed Mar 9 14:13 MAILER-DAEMON
root
p29C8wc02525 1828 Wed Mar 9 14:09 MAILER-DAEMON
root
p29C8wf02525 2947 Wed Mar 9 14:13 MAILER-DAEMON
root
p29C8we02525 3241 Wed Mar 9 14:13 MAILER-DAEMON
root
p29C8wg02525 4450 Wed Mar 9 14:13 MAILER-DAEMON
root


So how to identify the contents of each message?


F.R.

[Steven E. Protter]

Shalom,

sendmail -v -q

That will attempt to clear the queue and tell you why the mail is not moving.

If you don't care about the mail messages, you can simply delete the files in /var/spool/mqueue

SEP

[NDO]

Hi

I have identify the contents of those files, some say that there were errors delivering mail, and there will be no more attempts to deliver the mail. Some are headers, the others are ??
Is there a procedure to delete those files?

F.R.

[Jose Mosquera]

Hi,

First, check into /var/tmp, ussually you find a lot to delete there, check with fuser before remove.

You can force a massive mqueue purge with:
#sendmail -q

After this, if outgoing email keeps inside of /var/spool/mqueue obviously you have an issue with your sendmail service configuration, or, if you are a relay node your remote smtp service is dropped

Please make this sendmail test:
#echo "Hello"|sendmail -v your_emailaccount@yourdomain
Then, let me know the output of this.

Another question could be, Is it the first time this happens to you or you had never noticed it?

Anyway I could help you review your settings for emails and try to solve it. Of course, all this when you reach free space on / var, is critically priority! :)

Rgds.

[NDO]

Hi

I beleive it was because, the mail relay server was down, I can see that now a simple sendmail test is working , and /var is decreasing slowly. If the mail relay server goes down again, could I just stop sendmail until the mail admin fix it, would that be a solution?


F.R.

[NDO]

Hi

the test resulted in:

mcelbill[139]/ #echo "Hello"|sendmail -v fretagi@mcel.co.mz
fretagi@mcel.co.mz... Connecting to 192.168.1.39 via relay...
220 mail.mcel.co.mz Microsoft ESMTP MAIL Service ready at Thu, 10 Mar 2011 08:20:27 +0200
>>> EHLO mcelbill.mcel.co.mz
250-mail.mcel.co.mz Hello [10.1.20.21]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XEXCH50
>>> MAIL From: SIZE=6
250 2.1.0 Sender OK
>>> RCPT To:
250 2.1.5 Recipient OK
>>> DATA
354 Start mail input; end with .
>>> .
250 2.6.0 <201103100623.p2A6N9B16748@mcelbill.mcel.co.mz> Queued mail for delivery
fretagi@mcel.co.mz... Sent (<201103100623.p2A6N9B16748@mcelbill.mcel.co.mz> Queued mail for delivery)
Closing connection to 192.168.1.39
>>> QUIT
221 2.0.0 Service closing transmission channel


F.R.

[Jose Mosquera]

Hi,

According to command output your email test is *not* working:
250 2.6.0 <201103100623.p2A6N9B16748@mcelbill.mcel.co.mz> Queued mail for delivery

As you see, your email has been queued into /var/spool/mqueue.

>>could I just stop sendmail until the mail admin fix it, would that be a solution?
Yes, you can stop the sendmail service, but not, of course, the output queue generation. One of the reasons to be of a queue is store jobs for later delivery after the service restored. There are extreme solutions consisting rename command (sendmail, mailx, etc) that feed this queue. Personally I would not recommend this option, you better wait for your mail relay server is up again.

Rgds.