Solved /var/spool/clientmqueue does my partion out of free space

IPTRACE

IPTRACE

Hello, I have an issue due to creating a lot of files in queue directory (sendmail is disabled).
What are reasons for below data?

Code: 
user@serv:~ % sudo cat /var/spool/clientmqueue/dfx877B06e042475
/usr/libexec/save-entropy 42235 - - /var/db/entropy/saved-entropy.4 is not a regular file, and so it will not be rotated. Entropy file rotation is aborted.

user@serv:~ % sudo cat /var/spool/clientmqueue/qfx877B06e042475
V8
T1567840260
K1567840265
N1
P30461
MDeferred: Operation timed out with [127.0.0.1]
Fbs
$_operator@localhost
${daemon_flags}c u
Soperator
Aoperator@serv.mydomain
C:operator
rRFC822; operator@serv.mydomain
RPFD:operator
H?P?Return-Path: <▒g>
H??Received: (from operator@localhost)
        by serv.mydomain (8.15.2/8.15.2/Submit) id x877B06e042475;
        Sat, 7 Sep 2019 09:11:00 +0200 (CEST)
        (envelope-from operator)
H?D?Date: Sat, 7 Sep 2019 09:11:00 +0200 (CEST)
H?x?Full-Name: CronDaemon
H?M?Message-Id: <201909070711.x877B06e042475@serv.mydomain>
H??From: Cron Daemon <operator@serv.mydomain>
H??To: operator
H??Subject: Cron <operator@serv> /usr/libexec/save-entropy
H??X-Cron-Env: <SHELL=/bin/sh>
H??X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin>
H??X-Cron-Env: <HOME=/>
H??X-Cron-Env: <LOGNAME=operator>
H??X-Cron-Env: <USER=operator>
 
I'm betting those are stuck periodic(8) emails.

You should also check this cronjob:
Code: 
# Save some entropy so that /dev/random can re-seed on boot.
*/11    *       *       *       *       operator /usr/libexec/save-entropy
Apparently it's trowing errors and those get mailed to root.
 
My /etc/perdioc.conf file:

Code: 
daily_backup_aliases_enable="NO"
daily_backup_pkg_enable="NO"
daily_backup_pkgdb_enable="NO"
daily_clean_preserve_enable="NO"
daily_clean_rwho_enable="NO"
daily_status_pkg_changes_enable="NO"
daily_status_security_chkmounts_enable="NO"
daily_status_security_chkportsum_enable="NO"
daily_status_security_chksetuid_enable="NO"
daily_status_security_enable="NO"
daily_status_security_ipfdenied_enable="NO"
daily_status_security_ipfwdenied_enable="NO"
daily_status_security_neggrpperm_enable="NO"
daily_status_security_pfdenied_enable="NO"
daily_status_security_pkg_checksum_enable="NO"
daily_status_security_pkgaudit_enable="NO"
monthly_accounting_enable="NO"
monthly_statistics_enable="NO"
monthly_statistics_report_devices="NO"
monthly_status_security_enable="NO"
weekly_locate_enable="NO"
weekly_noid_enable="NO"
weekly_status_pkg_enable="NO"
weekly_status_pkg_enable="NO"
weekly_status_security_enable="NO"
weekly_whatis_enable="NO"

Moreover, I do not have entry in the crontab wrtitten by you.
 
IPTRACE said:
Moreover, I do not have entry in the crontab wrtitten by you.
Click to expand...
Well, I'm sure it's there, because that's the one you posted the email from:
Code: 
Subject: Cron <operator@serv> /usr/libexec/save-entropy

Don't disable it though, find out why it's producing errors. It's the errors that are emailed. If there are no errors it shouldn't send those mails at all.
 
Content of my crontab -l command.
Code: 
SHELL=/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
HOME=/var/log
MAILTO=""
 
Ok, I see it. So, the main question is why I get these errors. The new one.

Code: 
user@serv:~ % cat /var/spool/clientmqueue/qfx8A110uR085335
V8
T1568077260
K1568163666
N2
P123082
I0/74/803067
MWarning: could not send message for past 4 hours

Code: 
user@serv:~ % cat /var/spool/clientmqueue/qfx8B111h5055404
V8
T1568163666
K1568163666
N1
P34436
I0/74/803206
MDeferred: Operation timed out with [127.0.0.1]
Frs
$_localhost

I suppose above messages indicate no SMTP server works. I disabled sendmail.
 
IPTRACE said:
I suppose above messages indicate no SMTP server works. I disabled sendmail.
Click to expand...
Yes, correct. You can clear the queue just by rm -rf /var/spool/clientmqueue/*. Then keep an eye on it. As long as that cronjob keeps producing errors it will produce new emails.
 
How to avoid the following issues when sendmail is disabled in rc.conf ?

Code: 
user@serv:~ % sudo tail /log/sys/maillog
Sep 10 03:01:00 rc32 sendmail[85335]: x8A110uR085335: from=root, size=3082, class=0, nrcpts=1, msgid=<201909100101.x8A110uR085335@rc32.swimer.pl>, relay=root@localhost
Sep 10 03:01:05 rc32 sendmail[85335]: x8A110uR085335: to=root, ctladdr=root (0/0), delay=00:00:05, xdelay=00:00:05, mailer=relay, pri=33082, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Operation timed out with [127.0.0.1]
Sep 11 03:01:01 serv sendmail[55165]: x8B111qp055165: from=root, size=2606, class=0, nrcpts=1, msgid=<201909110101.x8B111qp055165@serv.swimer.pl>, relay=root@localhost
Sep 11 03:01:06 serv sendmail[55404]: x8A110uR085335: to=root, ctladdr=root (0/0), delay=1+00:00:06, xdelay=00:00:05, mailer=relay, pri=123082, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Operation timed out with [127.0.0.1]
Sep 11 03:01:06 serv sendmail[55404]: x8A110uR085335: x8B111h5055404: sender notify: Warning: could not send message for past 4 hours
Sep 11 03:01:06 serv sendmail[55404]: x8B111h5055404: to=root, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=34436, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: Operation timed out with [127.0.0.1]
Sep 11 03:01:06 serv sendmail[55165]: x8B111qp055165: to=root, ctladdr=root (0/0), delay=00:00:05, xdelay=00:00:05, mailer=relay, pri=32606, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Operation timed out with [127.0.0.1]
 
Those are the result of the original error message that got mailed. Flush the queue and fix the error that started it.
 
Anyway, I missed the three entries in rc.conf. I've added and check what will happen.
Code: 
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
 
It will still try to send mail regardless. Which is why I can't really recommend disabling sendmail unless you replace it with something else.

Why do you want to disable sendmail in the first place?
 
Yes, I can understand that, but now you disabled the daily security reports among others. And you won't be able to spot any errors generated by faulty cronjobs (like the one that started this whole ordeal). So in essence you're removing your ability to keep an eye on things, and that actually decreases your security.

If you have more than one server to maintain I would recommend NOT disabling sendmail and leave it running in the default "local submit only" mode. Then configure all your machines to send their local mail to a central mail server where you can collect all those reports and (cron) errors.
 
You must log in or register to reply here.
Back
Top