>FAIL dumper cobalt01.somewhere.nl /home 0 [data timeout]
>...
>Could it be because of MySQL (b)locking read-access to the tar process?
As Olivier said, it's unlikely to be a locking problem. Unix does not,
in general, apply mandatory locks. They are advisory, meaning a process
(such as a backup program like GNU tar) is free to ignore them.
If you watch the holding disk (or amstatus) while this is going on, how
big does the image get? I'm interested in whether it's zero length,
bigger than just the 32 KByte header, or if a lot of stuff got dumped
and then it stalled.
Here's another test. The /tmp/amanda/sendbackup*debug file on the client
shows the GNU tar command line used.
If you're doing a full dump (level 0), create a zero length temp
file someplace ("cp /dev/null /tmp/xxx").
Otherwise, look for the --listed-incremental flag file name. It should
have a ".new" suffix. A file with that same name but without the ".new"
should exist on the client. Copy that to the temp file.
Now, run the command sendbackup tried to run but change the file passed
to --listed-incremental to the temp file you just created. Send stdout
of GNU tar to /dev/null (with output redirection -- do **not** change
the --file argument) and see what happens.
You can either run it like this as the Amanda user:
.../runtar --create --file - ... > /dev/null
or run it as root:
gtar --create --file - ... > /dev/null
As an alternative to ignoring the output, pipe the first GNU tar
into a second that just does a catalogue ("... | gtar tvf -"). If it
consistently gets to the same place when it hangs, that will tell you
a lot about where the problem is.
If it works fine and amdump/sendbackup still does not work, it's going
to take some more head scratching (and probably some patches to try and
log what's going on -- are you up for that?).
>PS. the message is in plain text. ;-) ...
Thanks! :-)
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
