cancel
Showing results for 
Search instead for 
Did you mean: 

sendmail using CPU

SOLVED
Go to solution
S.S.
Super Advisor

sendmail using CPU

Dear All,

I want to know the following:

May i know why the sendmail is using CPU. In top the sendmail is using CPU.

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 ? 21899 root 158 20 458M 455M sleep 11:40 22.39 22.35 sendmail:
8 ? 22083 root 148 20 277M 273M sleep 4:58 19.39 19.36 sendmail:

I have checked
$ ps -ef|grep sendmail
root 1201 1 0 Jan 17 ? 70:39 sendmail: accepting connections on port 25
daemon 3666 21899 8 14:14:52 ? 0:00 sendmail: QAA04500: from queue
SN95599 3668 26577 0 14:14:52 pts/5 0:00 grep sendmail
root 22083 1201 219 13:37:43 ? 5:03 sendmail: HBX24033: from queue
root 21899 1201 255 13:07:38 ? 11:44 sendmail: QAA04500: from queue
root 25832 1201 192 14:07:48 ? 0:26 sendmail: DCT06491: from queue
$

May i know the reason?

Can send me the response early please.

Thanks !
19 REPLIES
Johnson Punniyalingam
Honored Contributor

Re: sendmail using CPU

may be your mail server , very busy

mails getting delayed in delivery of your mails

check any clues on /var/adm/syslog/syslog.log

Check on --> /var/spool/mqueue
Problems are common to all, but attitude makes the difference
Kapil Jha
Honored Contributor

Re: sendmail using CPU

You have lots of mails.....flow..that is why probably.....the only this I could see from above output.

BR,
Kapil+
I am in this small bowl, I wane see the real world......
Johnson Punniyalingam
Honored Contributor
Solution

Re: sendmail using CPU

# ls /var/spool/mqueue | wc --> to see how many

files are there, and look at what might be in

# /var/adm/syslog/mail.log.


Last resort I will try to stop & start sendmail

Restart sendmail

# /sbin/init.d/sendmail stop
# /sbin/init.d/sendmail start

Problems are common to all, but attitude makes the difference
Horia Chirculescu
Honored Contributor

Re: sendmail using CPU

Hello,

Take a look at:
/var/spool/mqueue

You can cat the files beginning with 'q' in order to find out from where the messages are coming and where the messages are sent.

The files beginning with 'd' contains the body of the messages.

Maybe you have a spammer in your LAN.

Horia.
Best regards from Romania,
Horia.
S.S.
Super Advisor

Re: sendmail using CPU

Hi Johnson,

I have checked the /var/spool/mqueue there are files generating from Feb 4 to till date and also the output of "$mailq -v" consists of number of jobs.

Thanks!
Kapil Jha
Honored Contributor

Re: sendmail using CPU

Just confirm is number of mails are reducing, if not then you will have to fix the issue.

If yes wait and watch :)

BR,
Kapil+
I am in this small bowl, I wane see the real world......
Johnson Punniyalingam
Honored Contributor

Re: sendmail using CPU

so a lot of mail is stacked up ??

if mails are important, -> no choices you need rectify what's problem so that stacked mails will be able to delivery properly,

if mails are not "important" you need remove them

best way to empty the mail queue is to run

Use "root" to perform below

# sendmail -q

This should clear it off if there is a connection issue.

If that does not work and it REALLY needs to be cleared

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

The -f supresses warning messages. (all messages are totally gone you can't recover)
Problems are common to all, but attitude makes the difference
S.S.
Super Advisor

Re: sendmail using CPU

Thank you!

May i know why the mails are delayed?
Horia Chirculescu
Honored Contributor

Re: sendmail using CPU

>May i know why the mails are delayed?

Can be many reasons for this. The smtp protocol is very good in management of this kind of delays.

You can find out the previous status of each mail waiting to be sent from the q* files.

Also, you should check your mail log (check syslog in order to find out your mail log location - possible /var/adm/syslog/mail.log)

Horia.
Best regards from Romania,
Horia.
Johnson Punniyalingam
Honored Contributor

Re: sendmail using CPU

>>May i know why the mails are delayed?<<<

Does your sendmail problem has been resolved ?




Problems are common to all, but attitude makes the difference
Johnson Punniyalingam
Honored Contributor

Re: sendmail using CPU

>>>>May i know why the mails are delayed?<<<

(remebered it from an old posting of yours) which I think is a server /var file system getting full.
you mentioned "empty mail" has dropped down the /var file system to 85%

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1405070

Other area to check is /var/mail/
This is the area that stores mail that has been delivered to a user acct. In this example, check the /var/mail/root file.

(As per my Experinece "the main problem I have encountered and relay proplem of Sendmail server)


deferred transmission due to transient address error

or something like that, it basically means the address you are trying to send mail to is currently not accepting email messages for some reason. More than likely, the subscriber has left the post he/she subscibed this email list

Or another scenario, there were so many documents to send to so many addresses, server is having hard time delivering these to the recipient servers

which one is your case. If it is the load problem, just wait over the weekend, it will subside tremendously by monday having majority of the messages delivered.
Problems are common to all, but attitude makes the difference
S.S.
Super Advisor

Re: sendmail using CPU

Dear All,

The rmail process is also running:

$ ps -ef|grep rmail
daemon 29997 3279 4 17:22:51 ? 0:00 rmail -d root
daemon 29995 24432 10 17:22:51 ? 0:00 rmail -d root
daemon 29974 18965 14 17:22:50 ? 0:00 rmail -d root
SN95599 29999 26577 1 17:22:51 pts/5 0:00 grep rmail
$

This rmail processes are running for every 5 seconds and it runs just a second.

May i know why it is running and what is rmail & what it does?

Thanks!
Horia Chirculescu
Honored Contributor

Re: sendmail using CPU

From: man rmail

RMAIL(8) RMAIL(8)

NAME
rmail - handle remote mail received via uucp

SYNOPSIS
rmail [-D domain] [-T] user ...

DESCRIPTION
Rmail interprets incoming mail received via uucp(1),


If you are not using UUCP, you should stop this from running on your server.

Horia.
Best regards from Romania,
Horia.
S.S.
Super Advisor

Re: sendmail using CPU

Hi,

In the subject of the email i have seen the I/O error.

It is like
451 I/O error

May i know the reason?
Horia Chirculescu
Honored Contributor

Re: sendmail using CPU

>In the subject of the email i have seen the I/O error.

Which email? You should give more info on this.

Maybe copy&paste the q* part of the message you are talking about.

Horia.
Best regards from Romania,
Horia.
S.S.
Super Advisor

Re: sendmail using CPU

Hi,

Please find:

more dfIAG10817
This is a MIME-encapsulated message

--IAG10817.1265333140/oradb3.canon.com.sg

The original message was received at Sun, 31 Jan 2010 09:15:42 +0800 (SST)
from localhost

----- The following addresses had permanent fatal errors -----
root

----- Transcript of session follows -----
mail: cannot append to /var/mail/root
mail: cannot create dead.letter
451 I/O error
Message could not be delivered for 5 days
Message will be deleted from queue

--IAG10817.1265333140/oradb3.canon.com.sg
Content-Type: message/delivery-status

Reporting-MTA: dns; oradb3.canon.com.sg
Arrival-Date: Sun, 31 Jan 2010 09:15:42 +0800 (SST)

Final-Recipient: RFC822; root@oradb3.canon.com.sg
Action: failed
Status: 4.4.7
Last-Attempt-Date: Fri, 5 Feb 2010 09:25:40 +0800 (SST)

--IAG10817.1265333140/oradb3.canon.com.sg
Content-Type: message/rfc822

Return-Path:
Received: from localhost (localhost)
by oradb3.canon.com.sg (8.9.3 (PHNE_29774)/8.9.3) with internal id IBX23059;
dfIAG10817 (27%) Sun, 31 Jan 2010 09:15:42 +0800 (SST)
Date: Sun, 31 Jan 2010 09:15:42 +0800 (SST)
From: Mail Delivery Subsystem
Message-Id: <201001310115.IBX23059@oradb3.canon.com.sg>
To: root
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="IBX23059.1264900542/oradb3.canon.com.sg"
Subject: Returned mail: Cannot send message within 5 days
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

--IBX23059.1264900542/oradb3.canon.com.sg

The original message was received at Tue, 26 Jan 2010 09:04:00 +0800 (SST)
from root@localhost

----- The following addresses had permanent fatal errors -----
root

----- Transcript of session follows -----
mail: cannot append to /var/mail/root
mail: cannot create dead.letter
451 I/O error
Message could not be delivered for 5 days
Message will be deleted from queue

--IBX23059.1264900542/oradb3.canon.com.sg
Content-Type: message/delivery-status

Reporting-MTA: dns; oradb3.canon.com.sg
Arrival-Date: Tue, 26 Jan 2010 09:04:00 +0800 (SST)

dfIAG10817 (61%)Final-Recipient: RFC822; root@oradb3.canon.com.sg
Action: failed
Status: 4.4.7
Last-Attempt-Date: Sun, 31 Jan 2010 09:15:42 +0800 (SST)

--IBX23059.1264900542/oradb3.canon.com.sg
Content-Type: message/rfc822

Return-Path:
Received: (from root@localhost)
by oradb3.canon.com.sg (8.9.3 (PHNE_29774)/8.9.3) id JAA02932
for root; Tue, 26 Jan 2010 09:04:00 +0800 (SST)
Date: Tue, 26 Jan 2010 09:04:00 +0800 (SST)
From: root
Message-Id: <201001260104.JAA02932@oradb3.canon.com.sg>
Subject: cron
MIME-Version: 1.0

printer "pr301" now disabled
printer "pr301" now enabled
printer "pr303" now disabled
printer "pr303" now enabled
printer "pr202" now disabled
printer "pr202" now enabled
printer "pr106" now disabled
printer "pr106" now enabled
printer "pr360" now disabled
printer "pr360" now enabled
printer "pr115" now disabled
printer "pr115" now enabled
/dba/sysadmin/scripts/check_prob_printer.sh[38]: print_job_pr215.lst: Cannot find or open
the file.


dfIAG10817 (90%)*************************************************
Cron: The previous message is the standard output
and standard error of one of your crontab commands:

/dba/sysadmin/scripts/check_prob_printer.sh


--IBX23059.1264900542/oradb3.canon.com.sg--


--IAG10817.1265333140/oradb3.canon.com.sg--

dfIAG10817: END


also

when i executed the command "mailq" there are number of jobs with I/O error.

--Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------
HAB04766 1651 Wed Feb 10 07:45 MAILER-DAEMON
(I/O error)
root
HAA04766 2217 Wed Feb 10 07:45 MAILER-DAEMON
(I/O error)
root
GCT06864 4584 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
HAC04766 4872 Wed Feb 10 07:45 MAILER-DAEMON
(I/O error)
root
GBH06864 9655 Wed Feb 10 07:41 MAILER-DAEMON
(I/O error)
root
GBJ06864 10650 Wed Feb 10 07:41 MAILER-DAEMON
(I/O error)
root
GBK06864 10745 Wed Feb 10 07:41 MAILER-DAEMON
(I/O error)
root
GBO06864 11511 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GBT06864 12501 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GBU06864 12601 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GBW06864 13067 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GBX06864 13439 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCA06864 14060 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCB06864 14166 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCD06864 15290 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCF06864 15721 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCI06864 40539 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCL06864 44021 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCO06864 49724 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCP06864 50308 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
GCR06864 53225 Wed Feb 10 07:42 MAILER-DAEMON
(I/O error)
root
IAA23302 194 Wed Feb 10 08:00 root
(I/O error)

I just posted few but number of there with the same error.

May i know the reason please?

Thanks !
Horia Chirculescu
Honored Contributor

Re: sendmail using CPU

mail: cannot append to /var/mail/root
mail: cannot create dead.letter

I believe your /var filesystem is full.

You should make some space there.

Horia.

Best regards from Romania,
Horia.
S.S.
Super Advisor

Re: sendmail using CPU

Hi Horia,

You are correct, the root account has stucked on Dec 29th due to that the mails are not delivering and sending an I/O error. The root account has been used up my entire /var filesystem.

Thank you!
S.S.
Super Advisor

Re: sendmail using CPU


Thank you All for spending your precious time.
Special Thanks to Johnson and Horia.