Launching the daemon as root works just fine.....I didn't even think 
about the library issue.....
the access time never changed on amandad until I changed the daemon 
owner.......now comes the fun part ot figure out which library has a 
permission issue......

But I should be able to discern that by he truss..at least I believe 
that should work...

Don

John R. Jackson wrote:

>>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