I'd reboot



Eric's email, phone







On Fri, Aug 7, 2020 at 2:32 PM -0600, "Diego Piñon Conde" 
<[email protected]> wrote:










qmailctl stop 
Stopping qmail-toaster: svscan qmail logging.
qmailctl starStarting 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]>) 
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]> 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]>) 
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 -sMessages 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
                    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
                    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
                    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
                    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
                    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
                    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
                    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
                    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
                    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
                    
                  
                
              
            
          
        
      
    
  



















Reply via email to