>Going thru the FAQ (which I did before I posted) ... Bless you!!! :-)
>#1. /var/adm/messages >Mar 14 21:59:45 db-dev inetd[158]: [ID 858011 daemon.warning] >/usr/local/libexec/amandad: Hangup Two things about this. First (the good news), it probably means you have all your service and inetd information set up right since inetd is able to detect an incoming packet and try to start amanda. Amandad is dying **very** early if it's not even able to create its debug file. Second, when inetd detects a mis-behaving service it "downs" it and will not listen for any new packets for (as I recall) 10 minutes. So after each test you either need to send a HUP to inetd to get its attention or wait a while. >#3. /etc/inetd.conf >amanda dgram udp wait amanda >/usr/local/libexec/amandad amandad Your mail wrapped this line and I'm sure it doesn't really look like this. Just make absolutely certain this is all on one line. In particular, if that trailing "amandad" is actually on the next line it will cause the kind of trouble you're seeing. If that's not it, here's the new two bigger hammers I pull out (from comment lines in my inetd.conf: # First debug trick -- create this shell script (chmod +x /tmp/amandad.test): # #!/bin/ksh # exec > /tmp/amandad.out.$$ 2>&1 # echo "$(/bin/date): starting amandad ($#): " "$@" # /opt/amanda/libexec/amandad "$@" # status=$? # echo "$(/bin/date): amandad done: status is $status" # exit $status # # amanda dgram udp wait backup /tmp/amandad.test amandad # # Next debug trick -- run amandad under truss: # # amanda dgram udp wait backup /bin/truss amandad -fo /tmp/amandad.truss /opt/amanda/libexec/amandad Make sure you adjust the paths as needed for your system. The idea of the first test is that inetd should not have a problem running this and it will redirect stdout and stderr from the "real" amandad to a temp file for examination. The second trick will log all the system calls involved in getting amandad started and hopefully something will show up there. >Also on my MP-RAS box I'm getting this error running selfcheck: > >ERROR: edaf6.irs.sat NAK: amandad busy >... >/tmp/amanda/amandad.20020315070227.debug: >... >amandad: received dup P_REQ packet, ACKing it > >sending ack: >... This debug file does not match the "amanda busy" message. You should see a line with "received other packet" in it. What happened in this particular report is that the selfcheck took a long while (30 seconds, unless you changed ctimeout in amanda.conf) so amcheck on the server tried again and amandad told it to go away, it was still busy with the first one. The same general section of code produces the "amandad busy" error, but in that case the packet looks to amandad like it is coming from some other host. You didn't accidentally have more than one amcheck or an amcheck and an amdump running at the same time, did you? It's probably a bad thing that selfcheck is taking so long. You might try running selfcheck by hand and see how long it takes. Take the lines from the "got packet" section, starting with "OPTIONS" and put them in a file someplace: OPTIONS ; GNUTAR /home/tp 0 OPTIONS |;bsd-auth;srvcomp-fast;index;exclude-list=exclude.txt; GNUTAR /eec/msg/logs 0 OPTIONS |;bsd-auth;srvcomp-fast;index;exclude-list=exclude.txt; GNUTAR /eec/data/test 0 OPTIONS |;bsd-auth;srvcomp-fast;index;exclude-list=exclude.txt; GNUTAR /eec/var/inf_dumps 0 OPTIONS |;bsd-auth;srvcomp-fast;index;exclude-list=exclude.txt; GNUTAR /eec/var/inf_archive 0 OPTIONS |;bsd-auth;srvcomp-fast;index;exclude-list=/usr/local/lib/amanda/exclude.gtar; GNUTAR /eec/var 0 OPTIONS |;bsd-auth;srvcomp-fast;index;exclude-list=/usr/local/lib/amanda/exclude.gtar; GNUTAR /eec 0 OPTIONS |;bsd-auth;srvcomp-fast;index;exclude-list=exclude.txt; Then run selfcheck **as the Amanda user** with that file as stdin. It will do the checks and write the results (about a dozen lines) to stdout. It might also be worth a look at /tmp/amanda/selfcheck*debug to see if it's complaining about anything. If you don't get anywhere with this, let me know and I'll give you some debugging code to find out where all the time is going. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
