Odd Sendmail Behaviour

[Sam Rudland]

I have a HPUX 11 server that is running sendmail. I can send mail (note the play on words!) okay - but I am seeing sendmail process' hogging CPU time to a long time. The ps listing says it is processing a message, but mail doesn't go out very often and a number of these process accumulate, until I start getting very high response times as a result.

Any ideas of how I can go about solving this??

Thanks in advance,

Sam

[linuxfan]

Hi Sam,

The problem might be caused by bad permissions.
The permissions should be

dr-xr-xr-x bin: bin /etc
dr-xr-xr-x bin:bin /etc/mail
-rw-r--r-- root:sys /etc/mail/aliases
-rw-r--r-- root:mail /etc/mail/aliases.db

After checking the permissions, stop and re-start sendmail
/sbin/init.d/sendmail stop
/sbin/init.d/sendmail -q -v
(to force immediate processing of sendmail's message queue)

-HTH
I am RU

[James R. Ferguson]

Hi Sam:

Knowledge Base document #KBRC00002189 suggests that this may be a permission problem:

/begin_quote/

PROBLEM
The sendmail process is at the top of the list as far as CPU usage. Attempts to stop sendmail using:
/sbin/init.d/sendmail stop
result in the following errors:

"hash map "Alias0": unsafe map file /etc/mail/aliases.db: world writable directory"
"hash map "Alias0": unsafe map file /etc/mail/aliases: world writable directory"

RESOLUTION
These types of problems often are due to a permission problem either on the /etc/mail/aliases, /etc/mail/aliases.db file, OR on one of the parent directories, namely /etc or /etc/mail.

To resolve the problem, make sure the following
permissions are set:

dr-xr-xr-x 29 bin bin 6144 May 10 12:30 /etc
dr-xr-xr-x 2 bin bin 1024 May 10 13:43 /etc/mail
-rw-r--r-- 1 root sys 835 Aug 30 1999 /etc/mail/aliases
-rw-r--r-- 1 root mail 32768 May 10 13:43 /etc/mail/aliases.db

/sbin/init.d/sendmail stop
should now work.

Re-start it using:
/sbin/init.d/sendmail start
and run:
sendmail -q -v
to force immediate processing of sendmail's message queue.

/end_quote/

Regards!

...JRF...

[Sam Rudland]

Perms were all okay - but I found in /var/spool/mqueue a massive amount of mail that was meant to have been sent over the past few weeks/months that appears to have never been processed!! These are mailings that should have come from cron jobs. Any ideas why there were so many not sent??

[James R. Ferguson]

Hi Sam:

I'd delete the ancient stuff.

...JRF...

[Sam Rudland]

Do you know there was 44254 old mails waiting to go?!?

The delete may take some time. When I ran the sendmail -q -v it was processing about 300 and then hanging on one indefinitely, this process then acted just like the others and started consuming CPU time while not appearing to do much else. Do you know of a way to find out more info about why it was hanging??

[Mark Vollmers]

Sam-

How does the mail.log look? does it say that there are any problems (like mail undeliverable)? You could look in the syslog for kicks as well.

mark

[Sam Rudland]

mail.log was massive. I have cleared out /var/spool/mqueue, there are a few items left, but a sendmail -q -v fails to process these items. It lists nine other items, one of which is destined for me. These items have sub-items (listed in mail.log) that I have deleted from the mqueue directory. Repeated sendmail -q -v's try to send these items still. Do you know how I flush the queue completely??

[linuxfan]

Hi Sam,

I think Mark meant check the mail.log, anyway,
before you noticed the problem was sendmail running? 44254 is a lot of mails, but did they indicate the cron job ran or failed? ;)
how long has the machine been up?
Just do a "grep rebooted /var/adm/syslog/mail.log" that would give an idea if anyone else tried bouncing sendmail on that machine.
But good your problem is resolved

-Regards
I am RU

[linuxfan]

Hi Sam,

If you don't really care about the mails in the queue, i think it is safe to delete all the files in the /var/spool/mqueue.

-Regards
I am RU

[Sam Rudland]

I rebooted the machine two weeks ago. The cron jobs all ran okay - sendmail appears to be broken though. Even after clearing the dir down mail is still getting stuck and customers do like their reports....! I checked sendmail.cf and the right queue directory is assigned.

Any sendmail experts around?!?

[linuxfan]

Hi Sam,

We had this problem once, where the messages would just queue up. Further investigation revelead that the load average on the machine was high. Sendmail (by default) only queues message when the load average gets above 8.

There are certain parameters in the sendmail.cf
QueueLA=8, change it a higher number.
Also there is another parameter RefuseLA=12, which indicates sendmail will refuse connections if the load average goes above 12. change these parameters to a higher number and restart sendmail.

That might help
-I am RU

[George Logiadis]

Sam,

You haven't said anything about the system and network configuration. If you're sending mails to the internet maybe there is bottleneck in your connection. Be also very carefull with big messages. Sendmail doesn't handle them very well and can even make the OS crash. If it is not a problem set the MaxMessageSize in sendmail.cf in to something small (a couple of Megs) and see if smaller messages are exchanged easier. From my experience the REAL problems in sendmail come either from a big number of huge mails or network routing and name resolving problems. Check them both...
Regards
George

[Sam Rudland]

Cheers for help all. Problem was nis was in nsswitch.conf for the aliases database when we have no nis map for that. Took it out and it processed the hundred odd mails backed up. Good thing I didn't try that when there were 40,000 mails waiting.......