Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3405
  • Last Modified:

sendmail filling the clientmqueue but mqueue says it's empty

I'm running a redhat 9 server with sendmail 8.12 or so. Everything has been working great for months except my clientmqueue directory is filled with 150 Mb of files spanning several months.

mailq says /var/spool/mqueue is empty (there are two files)
mailq -Ac says /var/spool/clientmqueue is empty (it is not!)

I tried a lot of the obvious stuff. reminded me that I need to have two sendmails running, and I do. Just for kicks, I ran a second copy of both:

sendmail -L mta -bd -q15m
sendmail -L msp -q15m

but all I get from that are a lot of daemon MTA: cannot bind errors in the maillog.

The files are mostly owned by smmsp.smmsp and have -rw-rw---- permissions, although there are a couple of apache.smmsp files.

Why isn't sendmail able to find and process that stuff?
  • 4
  • 4
1 Solution
A number of queued messages in /var/spool/clientmqueue means that either the MSP instance of Sendmail isn't running (it should be automatically started at boot by RH 9's /etc/init.d/sendmail script) or that is fails for some reason. The first thing to do would be to execute '/sbin/service sendmail stop' and make sure that all sendmail processes have died (check with 'ps -ef | grep sendmail | grep -v grep'). Then start sendmail with '/sbin/service sendmail start'. Check the tail end of /var/log/maillog for any errors and make sure that there is an MSB instance runningm like:

# ps -ef | grep sendmail | grep -v grep
root      5116     1  0 Mar20 ?        00:00:00 sendmail: accepting connections
smmsp     5125     1  0 Mar20 ?        00:00:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
jtw90210Author Commented:
Yes, jlevie. I suspected that it might be a 'not running' kind of problem based on other solutions to this problem, but there are two reasons why that doesn't seem to be the case. First, the todo list generated by mailq -Ac is empty. Second, I tested to make sure that both sendmails were running.

Last night I shut down both my existing sendmail processes (that started with init.d/sendmail) and started separate ones with
# sendmail -L mta -bd -q15m
# sendmail -L msp -q15m
while I tailed the maillog. Here are the only three errors incurred (other than bounces).

Apr  1 10:27:01 teddy mta[3712]: daemon invoked without full pathname; kill -1 won't work
Apr  1 10:27:01 teddy mta[3714]: starting daemon (8.12.8): SMTP+queueing@00:15:00
Apr  1 10:27:01 teddy msp[3718]: starting daemon (8.12.8): queueing@00:15:00

and the two sendmail processes appear in the ps.
I let it run all night like that and there were plenty of new entries in the directory, but none going away.
This morning I searched my maillog for messages from msp and I could only find the startup messages even though ps showed the same processes were still running.

For some reason it seems as though sendmail isn't able to see the messages. The contents of the messages that are in the directory seem to be predominantly mail reject bounces from mail sent to root@[mymachine] that doesn't accept mail, a lot of which are generated by cron. (I'll poke down that path for a while.)

The only other strange thing is that I get a lot of spam reject notices. Is it possible that my system might be compromised? How would I test for that?
jtw90210Author Commented:
Just now I was checking my ps and I have a lot of child processes:

# ps -ax | grep sendm
root      3714     1  0 10:27 ?        00:00:00 [sendmail]
root      3718     1  0 10:27 ?        00:00:00 [sendmail]
root      3838  3714  0 10:41 ?        00:00:00 [sendmail]
root      3942  3714  0 10:52 ?        00:00:00 [sendmail]
root      4113  3714  0 11:10 ?        00:00:00 [sendmail]
root      4114  3714  0 11:10 ?        00:00:00 [sendmail]
root      4115  3714  0 11:10 ?        00:00:00 [sendmail]

From the maillog I know 3714 is the mta while 3718 is the msp. So mta is working, but msp thinks it has an empty todo list.
A proven path to a career in data science

At Springboard, we know how to get you a job in data science. With Springboard’s Data Science Career Track, you’ll master data science  with a curriculum built by industry experts. You’ll work on real projects, and get 1-on-1 mentorship from a data scientist.

Is the content in /var/spool/clientmqueue valid qf/df pairs? A valid message will consist of a qf and df file with the same ID, e.g., qfi2ULRsBD025511 & dfi2ULRsBD025511. Failed mail transactions can result in either of the parts being present and won't ever get deleted since they can't be processed.

Does this system have a "stock RedHat" sendmail installation? By that I mean that you haven't replaced any of the parts of sendmail except as a result of running up2date?
jtw90210Author Commented:
yes, it is stock except for the conf -- I didn't compile it, but I did change a bit.  
yes, there appear to be two files for each entry, one beginning with 'Q' and the other beginning with 'd'.
The files themselves seem to be the output of cron jobs that I have that are getting bounced from the machine's root but aren't getting delivered to the bounce address. Almost a 'hop' problem. (That woundn't explain why it's not /trying/ though.)

# cat Qfi3305AST013867
${daemon_flags}c u
H?P?Return-Path: <g>
H??Received: from localhost (localhost)
        by (8.12.8/8.12.8/Submit) id i3305AST013867;
        Fri, 2 Apr 2004 16:07:16 -0800
H?D?Date: Fri, 2 Apr 2004 16:07:16 -0800
H?F?From: Mail Delivery Subsystem <MAILER-DAEMON>
H?x?Full-Name: Mail Delivery Subsystem
H?M?Message-Id: <>
H??To: root
H??MIME-Version: 1.0
H??Content-Type: multipart/report; report-type=delivery-status;
H??Subject: Returned mail: see transcript for details
H??Auto-Submitted: auto-generated (failure)

# head -30 dfi3305AST013867
This is a MIME-encapsulated message


The original message was received at Fri, 2 Apr 2004 16:05:10 -0800
from root@localhost

   ----- The following addresses had permanent fatal errors -----
    (reason: 553 5.3.0 <>... No email to this machine)
    (expanded from: root)

   ----- Transcript of session follows -----
... while talking to []:
>>> MAIL From:<> SIZE=17464
<<< 553 5.3.0 <>... No email to this machine
501 5.6.0 Data format error

Content-Type: message/delivery-status

Reporting-MTA: dns;
Arrival-Date: Fri, 2 Apr 2004 16:05:10 -0800

Final-Recipient: RFC822;
Action: failed
Status: 5.3.0
Diagnostic-Code: SMTP; 553 5.3.0 <>... No email to this machine
Last-Attempt-Date: Fri, 2 Apr 2004 16:07:16 -0800
Those are failed mail transactions. Since the message is from MAILER-DAEMON to root and since that's effectively from/to root and mail can't be delivered to root, the result is a failed mail transaction. That's shown by the presence of a Qf file, as oppossed to a qf file. Since Qf files represent a transaction that's in progress subsequent runs of the MSP won't clear them out.

You need to fix your system so that mail can be delivered to root. Not being able to do so affects not only local mail like this, but also mail transactions from to Internet sites and the loss of possibly important system notices.
jtw90210Author Commented:
Thanks, jlevie, I should have suspected sendmail would use something like labeling files with a Q to indicate failure instead of a  q to indicate that they are enqueued.

root stopped accepting email when I tried to block mail from outside but not localhost. I shut that off and now I'm getting system messages again (but also a load of spam.) Is there a quick and proper way to set up root like that?
> Is there a quick and proper way to set up root like that?

No, at least not without causing other problems.

Why not install an anti-spam package? Something like MailScanner (, which is my personal favorite, or MIMEdefang or AMaViS is pretty easy to install and helps lots with controlling spam.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now