Re: serialmail suddenly stops working

Paulo Jan <[email protected]> Wed, 26 Mar 2003 18:36:02 +0100
Newsgroups gmane.mail.serialmail
Message-ID <[email protected]>
>>	We had a DNS server crash during the weekend, and when it went
>>	back up Monday morning (which is when it all happened), the
>>	mail server started sending away all the mail that had been
>>	queued up in the previous hours. Which might have to do with
>>	the serialmail problem, but as I mentioned, the bandwidth
>>	usage wasn't high at all. Oh well...
> 
> 
> so check the DNS logs!  if i were in your shoes, i'd make sure i
> understand every tiny bit involved here.  hope you're not running
> complicated beasts like BIND.
> 


	Actually that was a hardware failure, so it was unrelated to the DNS 
server software itself. As for understanding what's going on, that's 
what I'm trying to do, but, I must admit, without much in-depth 
knowledge of TCP/IP's low level protocols. I'm almost sure that the mail 
server timeouts and the DNS server's coming-back-to-life are related, 
but I'm not exactly sure of how they interact. So, if it's not too 
off-topic, I'll summarize the problem again and ask for any ideas:


	1) Primary DNS server went down during Sunday, and outgoing mail got 
queued up in the mail server (which runs qmail) during that day.
	2) Monday morning I bring the DNS server up again, and the server 
starts delivering the queued mail.
	3) A couple of hours later, some users start reporting timeouts while 
trying to download their mail from outside our internal network. The 
same happens with one of the users using serialmail to receive his mail; 
serialmail timeouts, but telnetting by hand to his port 25 works fine.
	4) During all of the above, the bandwidth usage stats show high usage, 
but not higher than normal, and certainly not higher than in some 
traffic peaks that we've had.

	I'm speculating that too many UDP DNS requests might have bogged down 
our network, and that they don't show up in our statistics, but as I 
said, without having too much knowledge of TCP/IP internals, I'm not 
even sure of whether I'm on the right track.



					Paulo Jan.
					DDnet.