what happens when you try to start clamd@scan
# systemctl start clamd@scan
?
On 8/7/2020 3:07 PM, Diego Piñon Conde wrote:
Status of toaster services
send: up (pid 1083) 197 seconds
smtp: up (pid 1082) 197 seconds
smtps: up (pid 1081) 197 seconds
submission: up (pid 1092) 197 seconds
send/log: up (pid 1102) 197 seconds
smtp/log: up (pid 1080) 197 seconds
smtps/log: up (pid 1094) 198 seconds
submission/log: up (pid 1093) 198 seconds
systemd service: clamd@scan: [ FAILED ]
systemd service: clamav-freshclam: [ OK ]
systemd service: spamd: [ OK ]
systemd service: dovecot: [ OK ]
systemd service: mariadb: [ OK ]
systemd service: httpd: [ OK ]
systemd service: named: [ OK ]
systemd service: ntpd: [ OK ]
systemd service: sshd: [ OK ]
systemd service: network: [ OK ]
systemd service: crond: [ OK ]
systemd service: acpid: [ OK ]
systemd service: atd: [ OK ]
systemd service: autofs: [ OK ]
systemd service: smartd: [ OK ]
systemd service: irqbalance: [ OK ]
I do /systemctl stop/ /clamav-freshclam/ to stop freshclam
qmqtool -s
And local queue is descending painly slow yet . Sometime increase a
bit and then continue descending
El vie., 7 ago. 2020 a las 17:42, Eric's mail
(<[email protected] <mailto:[email protected]>>) escribió:
I'd reboot
Eric's email, phone
On Fri, Aug 7, 2020 at 2:32 PM -0600, "Diego Piñon Conde"
<[email protected] <mailto:[email protected]>> wrote:
/qmailctl stop
/
/Stopping qmail-toaster: svscan qmail logging./
/
/
/qmailctl star/
/Starting qmail-toaster: svscan./
/[root@pegasus etc]# supervise: fatal: unable to acquire
send/supervise/lock: temporary failure/
I have to /rm -f /var/qmail/supervise/send/supervise/lock/
then
/qmailctl start
Starting qmail-toaster: svscan/.
Uptime is 16hs Do you want I reboot the server?
}
El vie., 7 ago. 2020 a las 17:01, Eric's mail
(<[email protected] <mailto:[email protected]>>)
escribió:
Stop & start qmail. No errors should Come to the shell.
Did you reboot the host?
Eric's email, phone
On Fri, Aug 7, 2020 at 1:58 PM -0600, "Diego Piñon Conde"
<[email protected] <mailto:[email protected]>> wrote:
From what I can see in ps aux some processes are
repeated but from what I understand the main ones are
not repeated.
What information would be useful for you to help me?
El vie., 7 ago. 2020 a las 16:46, Eric's mail
(<[email protected]
<mailto:[email protected]>>) escribió:
Did you make sure only one instance of each qmail
program was running?
Eric's email, phone
On Fri, Aug 7, 2020 at 1:41 PM -0600, "Diego Piñon
Conde" <[email protected]
<mailto:[email protected]>> wrote:
Hi Philip
Yes, mail does get delivered with a very very
long delay. I'm still receiving many copies of
mails from yesterday at 3pm local time (more
than 10 copies in some cases).
Looking in the log, apparently clamav is
running self check every 600 sec, reading
/etc/clamd.d/scan.conf and not much more.
qmHandle -s shows
Messages in local queue: 3455
Messages in remote queue: 0
pretty the same that qmqtool -s
Messages in local queue: 3452
Messages in remote queue: 2
Messages in todo queue: 0
The amount of messages in the local queue is
still descending but I don't know why so slow!
El vie., 7 ago. 2020 a las 15:48, Philip Nix
Guru (<[email protected] <mailto:[email protected]>>)
escribió:
Hello
But the mail does get delivered just with
a very long delay ?
and you disabled clamd but it still running ?
Check a delivered mail, look at the
headers, make sure clamd is really not running
anything suspicous in
/var/log/clamd/clamd.log ?
qmHandle -s shows what ?
On 8/7/20 8:34 PM, Diego Piñon Conde wrote:
2 hs has passed and the local queue has
3530 msg (it was 3700 at some point).
Beside clamd that it is still running and
time to time take 100% cpu usage (I don't
understand why because qmailtoaster it's
supoust that not use it anymore), cpu
usage is normally below 20% and memory is
the same. So why does it take so long to
deliver local msg!
I'm in UTC -3, so probably all of you are
snoring. I will keep working til
qmailtoaster works normally, I hope when
you wake up you can give me a hand.
I will really appreciate that. Thanks in
advance!
El vie., 7 ago. 2020 a las 12:29, Philip
Nix Guru (<[email protected]
<mailto:[email protected]>>) escribió:
Hello
what you could start by doing is
disabling
idle-timeout-secs=xx in
/etc/spamdyke/spamdyke.conf
just comment the line
check in a few hours if your TIMEOUT
drastically decreased
then you can adapt the idle-timeout delay
If not then, we can check other things
Cheers
On 8/7/20 4:40 PM, Diego Piñon Conde
wrote:
Hi Philip
this is the tail of /var/log/maillog
/Aug 7 11:31:01 pegasus
spamdyke[2968]: TIMEOUT from:
[email protected]
<mailto:[email protected]>
to: [email protected]
<mailto:[email protected]>
origin_ip: 209.85.215.175
origin_rdns:
mail-pg1-f175.google.com
<http://mail-pg1-f175.google.com>
auth: (unknown) encryption: TLS
reason: TIMEOUT
Aug 7 11:31:03 pegasus
spamdyke[2970]: TIMEOUT from:
[email protected]
<mailto:[email protected]>
to: [email protected]
<mailto:[email protected]>
origin_ip: 209.167.231.144
origin_rdns:
mail01.messages.sonicwall.com
<http://mail01.messages.sonicwall.com>
auth: (unknown) encryption: TLS
reason: TIMEOUT
Aug 7 11:31:03 pegasus
spamdyke[2969]: TIMEOUT from:
v-cjcdika_pmnlhikcme_gmicmlkp_gmicmlk...@bounce.info.bancopatagonia.com.ar
<mailto:v-cjcdika_pmnlhikcme_gmicmlkp_gmicmlk...@bounce.info.bancopatagonia.com.ar>
to: [email protected]
<mailto:[email protected]>
origin_ip: 192.156.219.80
origin_rdns:
mail7756.info.bancopatagonia.com.ar
<http://mail7756.info.bancopatagonia.com.ar>
auth: (unknown) encryption: TLS
reason: TIMEOUT
Aug 7 11:31:06 pegasus
spamdyke[2974]: TIMEOUT from:
bounce-10710_html-121882056-2177875-6399888-...@bounce.mail.bbva.com.ar
<mailto:bounce-10710_html-121882056-2177875-6399888-...@bounce.mail.bbva.com.ar>
to: [email protected]
<mailto:[email protected]>
origin_ip: 13.111.6.12 origin_rdns:
mta.mail.bbva.com.ar
<http://mta.mail.bbva.com.ar> auth:
(unknown) encryption: TLS reason:
TIMEOUT
Aug 7 11:31:24 pegasus
vpopmail[3225]: vchkpw-submission:
(PLAIN) login success
[email protected]:10.10.10.8
<mailto:[email protected]:10.10.10.8>
Aug 7 11:31:27 pegasus
spamdyke[3004]: TIMEOUT from:
[email protected]
<mailto:[email protected]>
to: [email protected]
<mailto:[email protected]>
origin_ip: 91.211.241.9 origin_rdns:
pmta41009.emsmtp.com
<http://pmta41009.emsmtp.com> auth:
(unknown) encryption: TLS reason:
TIMEOUT
Aug 7 11:31:32 pegasus
spamdyke[3006]: TIMEOUT from:
[email protected]
<mailto:[email protected]>
to: [email protected]
<mailto:[email protected]>
origin_ip: 40.107.76.91 origin_rdns:
mail-eopbgr760091.outbound.protection.outlook.com
<http://mail-eopbgr760091.outbound.protection.outlook.com>
auth: (unknown) encryption: TLS
reason: TIMEOUT
Aug 7 11:31:34 pegasus
spamdyke[3050]: TIMEOUT from:
[email protected]
<mailto:[email protected]>
to: [email protected]
<mailto:[email protected]>
origin_ip: 190.210.19.10
origin_rdns:
webmail.provinciaseguros.com
<http://webmail.provinciaseguros.com>
auth: (unknown) encryption: TLS
reason: TIMEOUT
Aug 7 11:31:38 pegasus
spamdyke[3074]: TIMEOUT from:
[email protected]
<mailto:[email protected]>
to: [email protected]
<mailto:[email protected]>
origin_ip: 209.85.210.45
origin_rdns: mail-ot1-f45.google.com
<http://mail-ot1-f45.google.com>
auth: (unknown) encryption: TLS
reason: TIMEOUT
Aug 7 11:31:42 pegasus
spamdyke[3158]: TIMEOUT from:
[email protected]
<mailto:[email protected]>
to: [email protected]
<mailto:[email protected]>
origin_ip: 200.41.224.100
origin_rdns: mail.mardelplata.gov.ar
<http://mail.mardelplata.gov.ar>
auth: (unknown) encryption: (none)
reason: TIMEOUT/
I've checked scan.conf and
logverbose = yes
El vie., 7 ago. 2020 a las 11:27,
Philip Nix Guru (<[email protected]
<mailto:[email protected]>>) escribió:
Hello
can you check if you got any
TIMEOUT in /var/log/maillog log
file
since you did your update
Check also your scan.conf file
/etc/clamd.d/scan.conf
Enable Log (verbose) ,
LogVerbose yes
On 8/7/20 4:12 PM, Diego Piñon
Conde wrote:
Hi all
I'm running qmail toaster on
CentOS 7.
Because I had problems with
freshclam (terrible slow db
update), yesterday I changed
clamAV to Epel version.
I don't know if it's relevant,
but after that local delivery
was too slow.
Local queue was increasing in
size and every email received
by clients was received 5 or 6
times.
I thinked maybe clamd it's the
culprit, so I've changed
clamd=no in simcontrol and did
qmailctl cdb but nothing has
changed.
My knowledge is limited and I
will appreciate any help
