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]>) 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]> 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]>) >> 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] <[email protected]> to: >>>> [email protected] <[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] <[email protected]> to: >>>> [email protected] <[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 >>>> <v-cjcdika_pmnlhikcme_gmicmlkp_gmicmlk...@bounce.info.bancopatagonia.com.ar> >>>> to: [email protected] <[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 >>>> <bounce-10710_html-121882056-2177875-6399888-...@bounce.mail.bbva.com.ar> >>>> to: [email protected] <[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 <[email protected]:10.10.10.8> >>>> Aug 7 11:31:27 pegasus spamdyke[3004]: TIMEOUT from: >>>> [email protected] <[email protected]> to: >>>> [email protected] <[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] <[email protected]> to: >>>> [email protected] <[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] <[email protected]> to: >>>> [email protected] <[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] <[email protected]> to: >>>> [email protected] <[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] <[email protected]> to: >>>> [email protected] <[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]>) >>>> 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 >>>>> >>>>>
