>... However, I seem to get an awful lot of "NAK amandad busy"
>errors in my reports. ...
Hmmm. I'm not sure what would cause this, so here are the places I'd
start looking.
Make sure you're not accidentally running two amandad's (or an amcheck)
at the same time. I seem to recall one person fired off amcheck in the
background and then started amdump, for instance.
Look for any left over processes associated with your Amanda user. In
particular:
ps -fu <amanda-user>
ps -fe | egrep 'amandad|sendsize|sendback|selfch'
Or, if you have a "process tree" program:
ptree <inetd-pid> # or <xinetd-pid>
The last person who reported this problem found a stuck selfcheck process
that had gotten locked up in the kernel (which has got to be a kernel
problem as Amanda doesn't do anything odd). It took a reboot to clear
it up.
What's your inetd.conf (or xinetd config file) look like? In particular,
is "wait" set to "yes"?
What's in one of the /tmp/amanda/amandad*debug files on a machine that
has reported this error?
What's your disklist look like? In particular, is there any chance the
client hostname's are listed in multiple ways such that Amanda thinks
two entries are different machines when in fact they are only one?
For instance, I *could* (but would never) enter both "gandalf" and
"gandalf.cc.purdue.edu" in disklist for my workstation. But those look
like two different clients to Amanda and it would try to contact "them
both" at the same time, which would be a problem, although I'm not sure
it would generate an "amandad busy".
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
