Conference smurf::ultrix_mls_plus

780.0. "Mail queue backing up - question about locks" by RHETT::AMAN () Thu May 29 1997 16:20

    The customer is running MLS+ V2.1.  The system is acting as a mail
    server.  She is having problems with the mail queue backing up.  Even
    after rebooting the system, the mail queue doesn't completely flush
    out.  Another specialist talked to her about this, and here is his
    input.  We just have the question in the paragraph that starts with
    "Plan".  Any input on this is appreciated.
    
    Thanks!
    janet
    770-514-1050
    
    Mi:     The mail queue is backing up due to recipients who are              
            on remote hosts which are only online with the network              
            for one hour a day. Worst case is when there are 50 or              
            more of theses messages. The sendmail is running the queue          
            every 5 minutes. If an instance of sendmail blocks timing out       
            to these hosts, one after another for 2-3 minutes each,             
            then it fails to reach a queue entry down its list for              
            well after the hour window that particular host is reachable.       
            Then that host too winds up queued again.                           
                                                                                
            Customer has had to increase the default queue entry timeout        
            from 3 to 5 days to give it enough time to ultimately be
            delivered.     
                                                                                
            Another item is entries in syslog about locks on particular         
            mqueue jobs. There are no lock files and no locks since this        
            happens even after reboots. I do not know what kind of lock         
            this message is referring to. It looks like an MLS sendmail         
            feature.                                                            
                                                                                
    Plan:   Janet - please ask engineering about the syslog mail lock           
            messages to see if they can help there. I told Laura                
            they can help with that issue.                                      
                                                                                
            As for the mailqueue processing, I suggested the customer can       
            have crontab run a script which will fork off about 10-20           
            "sendmail -q" processes to run thte queue in parallel. This         
            technique cleared the queue very well when done manually.           
            Just be careful the sendmail processes do not cause to much         
            of a cpu load. Adjust the OX<typical max load avg #> option         
            in the sendmail.cf to prevent that.                                 
    
                                                                    

From:	SMURF::BAT          "Barbara A. Thomson ZKO3-2/X46 1-2955" 29-MAY-1997 16:39:19.59
To:	RHETT::AMAN
CC:	BAT
Subj:	re: TDS and sendmail problems


	Well, maybe they'll go back to running sendmail server on DEC MLS+!
	Just kidding -- just wanted to let you know I'm looking into this
	now.  The Plan sounds good.  I don't know about the "syslog entries
	about locks on particular mqueue jobs."  I'll have to find out about
	it. It would be helpful to have an exact message extracted from the
	syslog file, so I can look it up in the code to find out who is
	putting the message in the syslog file... 

	Also, here's a suggestion:  I would *decrease* the frequency that
	sendmail runs -- instead of every 5 minutes -- go to every 15 
	or something -- you are just loading up the system with useless
	work -- and what's worse, is that, the way sendmail works, it
	spawn off subprocesses to do the queue processing when it cannot
	get the job done in x amount of time, so you end up with a 
	bazillion subprocesses all doing the same work.

	Another thing -- when the systems come up that are down 23 hours
	of the day -- those systems should have a job (a la YP) that 
	goes an sends a message to the mail server to do the sendmail -q 
	-- then you would have real work done when and only when it needs
	to be done -- if you get mah drift?

	In the meantime, I'll see if there is something that jumps out
	at me.  

	BTW: The fix I sent them for the V3.1A sendmail that they claims
	did not work -- did JR ever reproduce the problem?  Or -- wait,
	I realize you may not even be aware of this.  They filed an
	IPMT against V3.1A sendmail because it would choke on too many
	things being queued up waiting to get mailed out.  I fixed a
	problem in sendmail, and gave it back to them, and they claim
	it doesn't fix the problem -- but what problem I don't know,
	because with my fix in place, I cannot reproduce a backup.
	I can have 100's of messages backed up, and they all get cleaned
	out when the system comes back on line -- so I need a description
	of the exact scenario that fails... I'm still waiting for that.
	Then they could go to an Alpha for the mail server.

	Later
	Have a nice vacation day tomorrow
	BAT