Hi,
Yesterday morning one of my DLEs failed the estimate phase, and it
happened again this morning.  The host is running Debian Linux with
software RAID devices (md).  Since I use a combination of dump and tar
among all my clients, I use disk names in my disklist wherever possible,
to keep everything consistent.  On the hosts that use tar, AMANDA
figures out the corresponding directory and everyone's happy.  For
safety, we'll call the host in question "<HOST>".

So, on <HOST> the failing DLE is disk "md0" which corresponds to /usr. 
Sendsize debug reports:

sendsize[29880]: estimate time for md0 level 1: 0.464
sendsize[29880]: no size line match in /bin/tar output for "md0"

"Aha!" I say.  Something's happening to tar and it's not completing the
estimate.  Running the tar command from a shell produces a segfault due
to a "permission denied" error on one of the directories below /usr:

backup@<HOST>:/usr$ /bin/tar --create --file /dev/null \
--directory /usr \
--one-file-system --listed-incremental \
/var/lib/amanda/gnutar-lists/<HOST>md0_1.new --sparse \
--ignore-failed-read --totals \
--exclude-from /tmp/amanda/sendsize.md0.20040609041435000.exclude .
/bin/tar: ./local/yoda: Cannot savedir: Permission denied
Segmentation fault


Now that's weird.  Shouldn't tar ignore such a permissions error, or at
least just warn on it and continue?  I have an identical host using the
same version of tar (GNU 1.13.25) with the same directory structure and
permissions.  It has no trouble with the estimate and AMANDA does not
indicate any strangeness with backing up that DLE.  Additionally, it has
been working for over a year on <HOST> and just started failing
yesterday.  The directory entry itself has not been modified in almost a
year.  I cannot think of what else could cause such a change in tar's
behavior.

Anyone have any ideas for further investigation?
Thanks,
Eric