Bug 2166213 - Unexpected CPU usage of sendmail
Summary: Unexpected CPU usage of sendmail
Keywords:
Status: NEW
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: esmtp
Version: epel9
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-01 07:32 UTC by mx
Modified: 2023-02-09 16:40 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description mx 2023-02-01 07:32:31 UTC
CPU will be used ~23% of one core by sendmail, which will be continuous used for 2-3 minutes. It is very strange for a email sender application.

cpu usage info in top:
```
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1597129 root      20   0  226160   5940   1940 S  23.1   0.0   0:02.14 /usr/bin/bash /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root
```

And this issue will appear once per 10 minutes. at every [00-02,10-12,20-22,30-32,40-42,50-52] minute

The esmtp package is installed while install fail2ban from epel9. However this issue still apears after stop of the fail2ban.service
And I did not findout any esmtp service.

Comment 1 Jaroslav Škarvada 2023-02-01 15:20:51 UTC
Make sure you run esmtp and not different MTA:
# alternatives --display mta

Try removing the queue, it could be corrupted, the queue should be '$HOME/.esmtp_queue', $HOME should be /root in this case.

Comment 2 mx 2023-02-01 23:37:28 UTC
it is estmp:
[root@host .esmtp_queue]# alternatives --display mta
mta - status is auto.
 link currently points to /usr/bin/esmtp-wrapper
/usr/bin/esmtp-wrapper - priority 30
 slave mta-sendmail: /usr/bin/esmtp-wrapper
 slave mta-sendmailman: /usr/share/man/man1/esmtp.1.gz
 slave mta-mailq: /usr/bin/esmtp-wrapper
 slave mta-mailqman: /usr/share/man/man1/esmtp.1.gz
Current `best' version is /usr/bin/esmtp-wrapper.


There is more than 20000 queue in 'root/.esmtp_queue'. 
It is no longer high cpu usage after rm all the queues in this folder. However, why all those queues are not send out? And there is empty in /var/spool/mail for root. note that, all those kind of info in this queue will send to /var/spool/mail/root in rhel7/centos7.

I only installed estmp withput any manual configuration.

Comment 3 mx 2023-02-01 23:39:42 UTC
I only installed estmp without any manual configuration.

Comment 4 mx 2023-02-03 09:16:36 UTC
May we just send all those queues into /var/spool/mail/root by default ?  Or just disable auto_send, do not send any thing in default.

The queues in my machine are from the outputs of the jobs scripts enabled by crontab. 

Before solved of this issue, I can reduce the generation of those queues by dropping those outputs to /dev/null in `crontab -e`.

Comment 5 mx 2023-02-03 10:10:59 UTC
Ok, default sending to local file, /var/spool/mail/root, is resolved by install esmtp-local-delivery:

```
dnf install esmtp-local-delivery
```

Comment 6 mx 2023-02-03 10:23:10 UTC
For users who want to delivery mails to their email, they should edit the configuration of esmtp. However I donot find any configuration files untill now, so can not mark any suggestion here.

Comment 7 Jaroslav Škarvada 2023-02-09 16:31:03 UTC
Are you sending the mail to local users or to remote users?

Esmtp doesn't have queues, the queue support is script hack, but it should work.

Comment 8 Jaroslav Škarvada 2023-02-09 16:40:54 UTC
Because if you are sending the e-mail to local users you of course need some e-mail server listening, because esmtp is send only (hence its name):

$ dnf repoquery --qf %{DESCRIPTION} esmtp
ESMTP is a user configurable relay-only Mail Transfer Agent (MTA) with a
sendmail-compatible syntax. It's based on libESMTP supporting the AUTH
(including the CRAM-MD5 and NTLM SASL mechanisms) and the StartTLS SMTP
extensions.

You can either install some MDA and use the esmtp-local-delivery or install full e-mail server.

So the e-mails are probably accumulating because esmtp is unable to connect to the e-mail server and the e-mails are remaining in the queue as undelivered.


Note You need to log in before you can comment on or make changes to this bug.