Re: Old song - timeouts

[mea@nic.funet.fi]

> On Tue, 21 Jul 1998 mea@nic.funet.fi wrote:
>>> problem? I have described it already two or three times, but here's what
>>> it's all about:
>> 
>>   Your problem was one of the reasons I rearranged my schedules.
> Glad to hear that ;-)
> 
>>> increases with the message size - the larger the message the more sure is
>>> the timeout. It all started to happen ever since I installed the s5
>>> release of zmailer. Now running s7, but it still timeouts... Well, I don't
>>> know zmailer sources well enough to find the reason, but maybe you will be
>>> able to help me out? The problem is that also VERY important servers (like
>>> netspace.org or mail2.redhat.com, rootshell) are timing out...
>> 
>>   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 ?

-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 ?

Myself I do use bleeding edge development kernels, and those
don't (usually) exhibit this kind of timeout problems.

>> 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

> 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.

Question (to myself):  Has  smtpserver/smtpserver.c:s_getc()  and friends
			been changed recently to cause this behaviour ?

/Matti Aarnio <mea@nic.funet.fi>