>Ok, I am ready to try debugging. ... I am not
>sure how to debug the server side ...
Take an amrecover*debug file from a failed run. Look for the lines
that start with ">". Those are commands amrecover sent to amindexd.
Run gdb as the Amanda user on the server and start amindexd with the
"-t" option. That tells it to run in interactive mode, i.e. you can
type the commands amrecover did (without the ">") and see the results
(the other lines from the debug file). Start with the "SECURITY" line,
skip the ones that reported an error. You might put the lines in a
file and run with it as stdin to save you typing them over and over.
For instance:
$ cat /tmp/xx.in
SECURITY USER root
DATE 2001-06-18
SCNF DailySet1
HOST localhost
DISK //myshare/install
OISD /
QUIT
$ gdb .../amindexd
...
run -t < /tmp/xx.in
I think your problem (assuming it has not changed) is in the "DISK"
command. When it is more or less happy, it calls build_disk_table,
which in turn calls find_dump. That routine does not appear to be
finding any information, or it is confused in some other way.
The first thing I'd do is step through find_dump with "next" (i.e.
step over any lower level routines) and get the general flow of how
things work. I'd also display a few results along the way to see where
things looked "odd" (i.e. a place I expected to get a result and did not).
In particular, make sure it calls search_logfile on each of your log
files. Check the value of "logs" after those calls to see if it's
finding anything. Or step into/through search_logfile to watch it run
as well.
Which reminds me. I forgot to ask you whether the log files had the
proper ownership and modes. You sent an "amadmin <config> find" output,
but I forgot to tell you to be certain to run it as the Amanda user
(and not root, for instance). You might also verify that amindexd is
being run as the proper user from inetd/xinetd.
It's possible gdb will give you grief about debugging some of these
routines if they are in a shared library. If that happens, rebuild
amanda with --disable-shared. And you may want to use --disable-libtool
so the amindexd file in the source area is the actual binary instead of
a shell script wrapper.
Note that you don't have to install amindexd to debug it. You should
be able to build it and debug from the source area.
>Also, can I get the "temporary debugging patches to amindexd to track what
>it's doing inside."?
:-)
There aren't any such patches (yet). What I meant was that if you got
things set up to debug but didn't want to use gdb, I (or you) could
stick some print statements in the code to trace the path, pretty much
like I outlined above with the debugger.
If you want to go that way (I can sympathise with not wanting to get into
the debugger -- they and I have a hate-hate relationship :-), let me know
offline (there's no sense annoying the rest of the list with our chatter)
and I'll put together a first cut at logging what's going on.
>Dan
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
