I think I should reply since I figured out I yet again had a typo in
inetd.conf. Unless adding "don't make a typo in inetd.conf or if you
do spot it" to the FAQ. What I really was looking for was a more
efficient manner of diagnosing the problems in response to the error
message.
On Fri, Jun 22, 2001 at 09:33:54PM -0500, John R. Jackson wrote:
> >When I run amcheck I get 'selfcheck request timed out' while trying to
> >connect to localhost ...
>
> First, don't use "localhost". It will bite you eventually. Use the
My best guess is it has bitten me many times.
> fully qualified domain name of the host. Any modern network code will
> notice they are the same thing and you won't lose any performance.
>
> >I remember getting this error on other installations. It seems to get
> >me every time I do a new install or even an update on an old machine.
>
> It is, by far, the most common problem for new installations. There are
> >... I
> >have found that with a machine with two ethernet interfaces, each with
> >its own IP and name, one will work and the other will fail. ...
I have problems because I'm almost alway using dual homed hosts where
I'll have one interface on the internet and typically a 192.168.1.x
interface on my local net. The problems come from getting the reverse
lookup to match the name look up. I'm not sure if this can actually
cause the "selfcheck request timed out" message.
>
> If you get a case like this again, please post and maybe we can look
> into what's going on and see if there is something Amanda could do to
> make it better.
I will the next time I set it another machine.
>
> >I have
> >found cases where I need to put both the user and the operator in
> >inetd.conf.
I meant to say where I need both the user and the group, in my case
operator.operator in inetd.conf. that was just typing too fast - which
is probably what happens when I make entries in inetd.conf
>
> Not sure I understood this one.
>
> >Does anyone have a complete list of what causes this error message? ...
>
> That's what the FAQ at www.amanda.org is for. Here are the main URL's
> about this particular topic:
>
> http://amanda.sourceforge.net/fom-serve/cache/16.html
> http://amanda.sourceforge.net/fom-serve/cache/140.html
>
> I think some of this is also covered in "the book chapter" referenced
> at www.amanda.org.
>
> >... I
> >keep thinking about what it could be and then I try something. If it
> >fixes it I stop (and forget exactly what I did to get it working). ...
>
> Instead of forgetting :-), how about adding an FAQ item yourself?
> You'll not only help yourself next time you run into the same thing,
> you'll also be helping other people.
I would if they weren't already in the FAQ. My problem is not that I
ever come up with a new problem but that it is hard to diagnose it. I
did look at those pages. And I will look at them again and will
readily acknowledge my need to go through more thoroughly. I
downloaded and installed lsof. But I didn't know what files to look
for when I ran lsof. I saw some of the pieces running, that is some
files that were obviously part of amandam, and thought they all were.
I also tried downloading the C programs, gethostbyname.c,
gethostbyaddr.c, and getservbyname.c, to help figure what was
happening. For some reasons I will examine later I was unable to get
them to compile on the machine I am running amanda on.
I also looked through the tmp directory, and probably should have
figured out staight away that the amandad wasn't being started through
inetd because the files were too short. But of course that's what I'd
expect with the timeout message.
It feel that I should have gotten the mechanics of testing down; but
somehonw I haven't. I'm not sure what, if anything, I really should
have asked. I suspect the answer was run top, i.e. "top -Uoperator"
and watch to see that an amandad process and at least a second amcheck
progress starts. Though even in this case I'm not really sure what I
should see.
--
Josh Kuperman
[EMAIL PROTECTED]
