>... What I really was looking for was a more
>efficient manner of diagnosing the problems in response to the error
>message.
Here's the order I would do things after adding the entry and HUP'ing
inetd (or the equivalent for xinetd):
* Look at whatever system log inetd writes to and make sure it
didn't complain about anything. For instance, if you forgot to add
the amandad service to /etc/services, inetd will whine to the log
file about a bad service name.
It might even be useful to deliberately put a bad entry in the file
just to see where error messages get logged.
* Run "netstat -a | grep amanda" and make sure someone (inetd) is
listening on the amanda port(s). If not, you for certain have an
inetd problem and there's no point going further. It might be as
simple as having forgotten to do the HUP. Or it could be some typo
in the line (which probably would have been logged).
* Run "amcheck -cl <config>" on the tape server (after updating
disklist, etc). If it times out, the first thing to check is the
files in /tmp/amanda on the client. If you don't see an amandad*debug
file at all, inetd was not able to start it for some reason. Back to
the log files, or try the "run it by hand" test.
If the file is there, check it for errors and also look for the
corresponding selfcheck*debug file, although things rarely get this
far and still fail.
At least part of the difficulty with all this is the differences
between OS's. For instance, you mentioned setting the user and group
in inetd.conf. None of my OS's support that, so I wouldn't have had
any idea to advise you to look for that type of problem.
>Josh Kuperman
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
