[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
> 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...
> (2) I tried setting USE_FCNTLLOCK in transports/libta/lockaddr.c. After
> futzing with the header files to get fcntl.h incorporated, this code
> did not build. Looking at the fcntl code in lockaddr.c, I don't think
> this code works.
No, it does not work. I did never finish off the code.
(And I am not certain it would be cheaper to the system,
than the current method -- having HUNDREDS of small log
regions in dozens of files...)
> (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 ?
> (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.
- Router HUP -- You must HUP the GROUP, not single ("top parent")
process that forked off some siblings to do paral-
lelized routing
- 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...
- 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.
> (5) process.cf has a return 0 just prior to the log info: line that prevents
> the info: line from being generated. This, of course, breaks any stats
> gathering you might want.
>
> (6) I can't find any documentation about the output of mailq -Q. Can someone
> describe the following please?:
> smtp/mx1.gzic.gd.cn/0 R=9 A=3 P=22688 HA=1482s FA=1484s OF=9 QA=14h18m56s
R = Recipient addresses in the thread
A = Attempts done on this channel/host selector
P = Process PID of the Transport Agent
HA = Hunger Age -- when it last reported a need for "food"
FA = Feed Age -- when a job was sent to the TA
OF = OverFeed -- how many jobs are still unprocessed by the TA from
those that were sent to it ?
QA = QueueAge -- Age of the oldest message in the thread
> (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.
> Thanks!!
>
> /mrg
/Matti Aarnio <mea@nic.funet.fi>