[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues for Solaris 2.5.1 and 2.99.45
On Tue, 18 Mar 1997 20:13:37 +0200 mea said:
> > Solaris 2.5.1
> > Zmailer 2.99.45
> >
> > A few problems. I tried pushing about 100,000 messages through it
> > as my first acid test (real traffic).
> >
> > (1) Logging scheduler output I got 53MB of the following message type:
> >
> > 19970317192004 DBGdiag: # smtpclient:15563: lockaddr: file '541305-13635' host
> > '?host?' expected '~' found ' '
>
> It means that two smtp-clients have been processing same message
> in parallel. It is a no-no situation actually.
>
> The presense of '?host?' propably means that you are running
> scheduler without sending host-selectors down to the TA programs.
> That is, you have the smtp/* defined in the ancient manner of:
> command="smtp $host"
>
> Umm.. No, it doesn't look like it from things you describe below.
> Hmm...
>
As you figured out... I am not specifying "smtp $host". I am doing "smtp -e
-s".
> > (3) I have 6 smtp processes looping, apparently. I am unable to truss or
> > debug them. I sent them a SIGABRT and then gdb the core file and got:
> >
> > #0 0x148b0 in process (SS=0xeffff3c8, dp=0x3fb7c, smtpstatus=0, host=Cannot
> > access memory at address 0xeffff184.
> > ) at smtp.c:701
> > 701 for (rp = rphead = dp->recipients; rp != NULL; rp = rp->next) {
>
> ??? Perhaps a faulty transport-spec file ?
Ok. Not sure where I should look for this... Any help is appreciated.
>
> > (4) HUPing the scheduler process does not cause new processes to write a new
> > scheduler.perflog. Killing the scheduler process does not kill the children,
> > as documented. HUPing the router process only causes that one router process
> > to write to the new log file, the others continue writing to the old (it would
> > seem they never get HUPed).
>
> - Scheduler HUP -- The logfn processing (of log file) is handled by
> the lib/loginit.c routine, which does not know
> about the perflog.
I presume I should disable the perflog then... since it would seem
that there aren't any programs to grok this information for useful reporting,
yes? I guess I would point the perflog and /dev/null so I can get the
nice -Q output, yes?
>
> - Router HUP -- You must HUP the GROUP, not single ("top parent")
> process that forked off some siblings to do paral-
> lelized routing
How is this done? Sorry for such a stupid question.
>
> - The children of the scheduler will die some day, once they are done
> with all the job-specs they have received. However smtp connection
> timeouts (for example) are not always very short...
Can there be an option to the scheduler which says that it should send
a SIGTERM or SIGKILL to all children??? Then I can reliably roll over
the scheduler log file.
>
> - For the 2.99.47 I have done some checking on SMTP timeouts, and
> how sure they are to happen. Perhaps I have now been able to
> improve the sureness a bit now.
good.
> > (7) What is considered to be the last 'stable' release of zmailer? Is anyone
> > moving 200,000 messages per day on Solaris 2.5.1???
>
> I have 2.99.46p3 at mailhost.utu.fi, though I don't know
> how many mails it processes daily -- fairly many..
> .. and no, I would not call 46p3 STABLE, for that matter
> all of 46 are somewhat buggy.
Is there a previous version I should go to instead??
/mrg