Well, to be honest, it was pissing me off. I had no way to verify what
problems were caused by a timeout, no authorization, improper setup, but what
was happening was (I found this out by running planner by hand) that planner
itself was getting this error, "Connection packet receive: connection timed
out" or something very similar (I wiped the log.) but it was showing up in the
amdump reports as "RESULTS MISSING" on ALL drives, as well as a quickie at the
end stating that it got an "empty schedule from planner." Well, talk about no
mention of either problem in the FAQ! or at least not the problem that I was
having. The "RESULTS MISSING" on my systems has NOTHING to do with the size of
the UDP packet being transfered, but the fact that planner would not even run
(and exit with 0).
I have since gotten planner to run on it's own via amdump, as well as command
line, and have stopped receiving those errors. I'm not sure why it was having
trouble indexing the drives, but it seems to *not* have that trouble any more.
Neither the sendsize.debug nor the amandad.debug report any problem or error's
with the run, all I ever see is amandad: got ack: and some other
versioning/debugging output, none of which states anything about any problems.
I'm sorry if the info I'm giving you isn't much, but there's not much to be
found. amdump's mail's give a vague description of a problem and there isn't
much of a way to cross-reference that except the monthly archives/FAQ-o-Matic
for which you have to determine the problem and the resolution to be any good.
(hence defeating the purpose of the faq, to answer your unanswered question,
maybe using the faq-o-matic could be used in determining what problems are,
but as a reference for vague errors that could potentially be caused by many
things, it just isn't enough.) Now that planner is indexing drives, things
seem to be running A LOT smoother, such as amdump running all the way through,
planner index's, taper records, etc. Thanks for the fast action on the mailing
list, you've made one (I'm sure many more.) admin happy. Next task, punch a
hole in the firewall for the web/ftp and I'll be golden.
Thanks again,
Tom Hudak
On Mon, Nov 13, 2000 at 02:49:47PM -0500, John R. Jackson wrote:
>Dare I ask **why** you're trying to run planner by hand? I noticed the
>Subject on the previous E-mail was "Selfcheck timeout". Do I infer from
>that that one (or more) clients are having this issue?
>
>Since you're not getting a "connection refused" type error, I'm
>guessing amandad/sendsize are getting started on the client, but it
>would be useful to see that output (/tmp/amanda/amandad*debug and
>sendsize*debug). One possibility is that it is taking a long time to
>gather the estimate (for some reason) and that Amanda is getting tired
>of waiting. The etimeout configuration parameter controls that, or it
>might be something wrong with the client (or dump program) itself.
>
>>Tom Hudak
>
>John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
PGP signature