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