Re: Old song - timeouts

[VIP Lists Account <viplists@vip.maestro.com.pl>]

On Tue, 21 Jul 1998 mea@nic.funet.fi wrote:

> >>   Lets try to see what happens.  Your system is Solaris ?
> > Nope. It's Linux.
> > 
> >> Which version ? (2.5.*, 2.6.* ?)    ZMailer 2.99.50-s7 ?
> > 2.0.35, zmailer 2.99.50-s7
> 
> Hmm...  Linux 2.0.32+ are "maintance releases", I wonder what
> has changed in the 2.0.34/2.0.35 ?
Quite a lot! Take a look at the Alan Cox' page at
http://roadrunner.swansea.uk.linux.org/relnotes.35.html.
> 
> -r--r--r--   6842843 Jun  4 05:15 linux-2.0.34.tar.gz
> -r--r--r--   7014087 Jul 13 21:09 linux-2.0.35.tar.gz
> 
> Could you check when your kernel was changed, and how those
> changes altered ZMailer behaviour ?
AFAIR, the problems started when I upgraded to the .34 kernel...
I'll see what has changed in the networking code that could
affect zmailer. Unfortunately I switched zmailer version at exactly that
same time and so I thought it might be some problem introduced in that
version.

> Myself I do use bleeding edge development kernels, and those
> don't (usually) exhibit this kind of timeout problems.
Hmm... I'm fighting with myself to use the dev kernel on my server (at
home I'm on 2.1.x since almost the very beginning)... OTOH,
ftp.uk.linux.org runs on 2.1.106... hmm... I think I'll give it a shot and
see whether it helps. If it does, then I'll try to track down what might
be the cause of the timeouts.

 > >> You will recognize the cases with filenames of type:
> >> 	1234.DATA-EOF
> >> 	1234.SMTP-TIMEOUT
> >> 
> >> Now, which happen ?
> > Both of them. 95% are timeouts, the rest premature DATA EOFs
> > 
> >> What the smtpserver log tells about these sessions on which these
> >> messages were received (sorry, no easy way to identify process ids
> > Attached are typical examples of what happens. Both timeout and eof are 
> > in this file. I haven't removed the server addresses for the purpose -
> > perhaps anyone experiences similar problems with them? Only the usernames
> > were removed to protect their privacy.
> > 
> >> from the spoolfiles.  Propably must try to add a way to log that
> >> trapped spoolfile name into the log -- or store PID into the spool
> >> file.. Hmm...)
> > Hmmm... perhaps add an option to log every smtpserver session to a
> > separate file named connecting-party.ident.smtpserverpid and leave the
> > file on disk ONLY if the session fails for some reason.
> 
> Using options:
> 	-l $MAILLOG/smtpserver -S remote
> on the smtpserver you will get logging into:
> 	$MAILLOG/smtpserver.remote-host-name
Thanx. I know ;-)))) - RTFM, sorry ;-))

> > BTW. I noticed that changing the timeout values in smtpserver.h doesn't
> > help a single bit. That precisely (and a quick look at the smtpserver
> > code) gave me the idea that there must be something wrong with the alarm()
> > usage. Don't you think that it would be better to use some form of virtual
> > timing (e.g. by virtualizing timers with setitimer?)
> 
> Nope, nothing in the timers has changed to cause this type of problems.
But how would you explain that changing the timeout values in smtpserver.h
doesn't affect the smtpserver behavior at all?