[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does anybody have problems with 2.99.52-pre3 ?

On Fri, 24 Sep 1999, Matti Aarnio wrote:

> yes, I have heard of ETRN queue timeout problem, although I don't yet
> understand how it can happen -- it is a scheduler issue, and nothing
> scheduling related has been done there since 29-Jun-1999 (before
> 2.99.41-pre1 - CVS tag, apparently, as there isn't separate tarball).
> Even then, real scheduling changes should be far older, like at least
> 6 months, perhaps more (I just stopped around april 1999 for
> the backtrack).

Well....I see the ta/smtp binary not behaving good on Solaris 2.6 with
2.99.51 as reported.
After 24 hours uptime the ta/smtp's from the bootup are still around,
while they normally aren't.

I've replaced the ta/smtp binary with the one from 2.99.50s17 and my
problem is solved. The binary's now disappear correctly.

What I gues that's happening:
* zmailer bootclean
* zmailer (normal startup)
* queue processing
  - hosts online are correctly served, binary disappears correctly after
  - clients not online, binary stays forever (until manual next restart of
    Zmailer). The status of the mails it is working on is now 'thread
    wait' and sometimes the normal queued status.
 After more then 12 hours, the queue status is still the same for the
'thread wait' mails...notting happened, not even if the customer was
online sometime during that 12 hours. His mails stays in queue
An etrn command doesn't make any impact on customers in 'thread wait'

With the old ta/smtp my queue is processed within 4 minutes and all mails
are correctly queued and after that processed. Thus if a client comes
online, an etrn command is issued and his mail is being delivered.

This problem is most visible with our etrn host (handles smtp-etrn only)
and less on smtp-relay and fallback mx servers.

In ta/smtp.c much work is done after 2.99.50s17, and i notice a 'timeout
for solaris 2.5' entry. Maybe this is related ?

Willing to test solutions. Mail me private.

Another problem I noticed lately and over which I sent you an email was
'etrn expiring fast'. This problem I've (as far as I can see) succesfully
solved last wednesday. Haven't had the time to mail you that yet.

It turns out that the retries line in smtp-etrn was wrong on our side.
Since a little more then one year it was retries="86400 86400 86400".
Before 2.99.51 Zmailer didn't do something weird with it, but now it does.
Making it the default retries="12" solved the expiring fast problem.

4 new Zmailer machines in one week, 2 relays and 2 fallbacks.

Mark Visser / Calslaan 26-31              | E-mail: mark@dnd.utwente.nl
7522 MC Enschede / Telephone: 053-4895038 | SNT-mail: mark@snt.utwente.nl
Warning: You can get rid of all the bugs by disabling them from the main menu.