If clamav is really disabled and not scanning messages you could safely stop its daemon to free memory and cpu so delivering should run faster.
Em 2020-08-07 16:40, Diego Piñon Conde escreveu: > 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]>) 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]>) 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] to: [email protected] origin_ip: > 209.85.215.175 origin_rdns: mail-pg1-f175.google.com [1] auth: (unknown) > encryption: TLS reason: TIMEOUT > Aug 7 11:31:03 pegasus spamdyke[2970]: TIMEOUT from: > [email protected] to: [email protected] origin_ip: > 209.167.231.144 origin_rdns: mail01.messages.sonicwall.com [2] 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 > to: [email protected] origin_ip: 192.156.219.80 origin_rdns: > mail7756.info.bancopatagonia.com.ar [3] 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 to: > [email protected] origin_ip: 13.111.6.12 origin_rdns: > mta.mail.bbva.com.ar [4] 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 > Aug 7 11:31:27 pegasus spamdyke[3004]: TIMEOUT from: > [email protected] to: [email protected] origin_ip: > 91.211.241.9 origin_rdns: pmta41009.emsmtp.com [5] auth: (unknown) > encryption: TLS reason: TIMEOUT > Aug 7 11:31:32 pegasus spamdyke[3006]: TIMEOUT from: > [email protected] to: [email protected] origin_ip: > 40.107.76.91 origin_rdns: mail-eopbgr760091.outbound.protection.outlook.com > [6] auth: (unknown) encryption: TLS reason: TIMEOUT > Aug 7 11:31:34 pegasus spamdyke[3050]: TIMEOUT from: > [email protected] to: [email protected] origin_ip: > 190.210.19.10 origin_rdns: webmail.provinciaseguros.com [7] auth: (unknown) > encryption: TLS reason: TIMEOUT > Aug 7 11:31:38 pegasus spamdyke[3074]: TIMEOUT from: > [email protected] to: [email protected] origin_ip: > 209.85.210.45 origin_rdns: mail-ot1-f45.google.com [8] auth: (unknown) > encryption: TLS reason: TIMEOUT > Aug 7 11:31:42 pegasus spamdyke[3158]: TIMEOUT from: > [email protected] to: [email protected] origin_ip: > 200.41.224.100 origin_rdns: mail.mardelplata.gov.ar [9] 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]>) 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 Links: ------ [1] http://mail-pg1-f175.google.com [2] http://mail01.messages.sonicwall.com [3] http://mail7756.info.bancopatagonia.com.ar [4] http://mta.mail.bbva.com.ar [5] http://pmta41009.emsmtp.com [6] http://mail-eopbgr760091.outbound.protection.outlook.com [7] http://webmail.provinciaseguros.com [8] http://mail-ot1-f45.google.com [9] http://mail.mardelplata.gov.ar
