>Jan 29 13:48:18 helix inetd[189]: [ID 858011 daemon.warning] 
>/usr/bin/truss: Hangup
>...
>Jan 29 13:50:28 helix inetd[189]: [ID 858011 daemon.warning] 
>/tmp/amanda_test: Hangup

Something is seriously wonky about your system if you can't run these
things.  Try one more test without Amanda in the loop at all:

  amanda    dgram  udp wait   amanda /bin/sleep sleep 4

If that also does the Hangup (amcheck will fail, but that's not important
at this point), then I have no clue.  Well, maybe one ...

>I can truss the amandad with no problem as well as determine what 
>arguments and exit status by running from the command line....

When you run things by hand, they have a different environment (in many
ways) than when inetd runs them.  It can be a real pain figuring out
what the difference is.

When you ran things by hand, did you run them a "amanda"?  In
particular, did you do something like this:

  su - amanda -c "/var/adm/amanda/libexec/amandad"

The leading '-' tells "su" to set up the environment as though the
user had logged in (i.e. it does not inherit whatever you have).
And specifying the full path makes sure $PATH isn't getting you a
different version of the program.

If that's not it, and the sleep also fails, try using sleep again but
change "amanda" to "root".

If that also fails, there is something wrong with the way your system
is set up, but without looking at it myself I wouldn't have the faintest
idea where to start.

If root works but amanda fails, you've may have some kind of permissions
problem.  Since amandad (et al) are dieing right at the start, I'd guess
a shared library.

One other thing you could try is truss (-f) inetd itself to watch
the amanda service (I'd still use sleep at this point) get started.
The problem could easily be that the forked inetd child is having the
problem and never even getting to the other program (sleep, amandad,
truss, etc).

Speaking of which, did you check the access time on amandad after trying
amcheck?  If it's not getting updated, that also means it's probably
the inetd child failing before it can exec the real program.

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to