From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: After the latest update to tar, amanda backups fail due to tar running seemingly forever. For two mornings in a row since the tar update, tar has been running 6 hours after being started by amanda. I've had to kill it each time. Here is what it is doing: neuromancer> ps -ef | grep tar root 26666 22665 47 04:15 ? 01:06:00 /bin/tar --create --file /dev/null --directory /usr/local --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/neuromancer_usr_local_1.new --sparse --ignore-failed-read --totals . root 26683 22689 45 04:16 ? 01:02:12 /bin/tar --create --file /dev/null --directory / --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/neuromancer__1.new --sparse --ignore-failed-read --totals . tjb 29096 29073 0 06:35 pts/0 00:00:00 grep tar neuromancer> Version-Release number of selected component (if applicable): tar-1.15.1-7.FC4, amanda-2.4.5-2 How reproducible: Always Steps to Reproduce: 1. install the new tar and have an amanda backup run 2. 3. Actual Results: the amanda backup times out to the server and the tar command used to send the size of the backup to amanda is still running many hours after it should have been done. Expected Results: tar should finish in a resonable time. Additional info: Previous version worked fine.
see this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154882 i think u should reduce /var/log/lastlog size.
How do you reduce the lastlog size? It's not mentioned in the bug.
#cd /var/log #rm lastlog #touch lastlog
This doesn't seem to be an acceptable solution since you lose all lastlog data. Are you suggesting that this be done every night before backup? Also, this was working fine with tar-1.15.1-5, it just broke with 1.15.1-7.FC4. The changelog says * Wed Jul 27 2005 Peter Vrabec <pvrabec> 1.15.1-7.FC4 - exclude listed02.at from testsuite * Wed Jul 27 2005 Peter Vrabec <pvrabec> 1.15.1-6.FC4 - A file is dumpable if it is sparse and both --sparse and --totals are specified (#154882) - exclude err.patch, it causes SEGV (#158743) * Fri Apr 15 2005 Peter Vrabec <pvrabec> 1.15.1-5 - extract sparse files even if the output fd is not seekable.(#154882) - (sparse_scan_file): Bugfix. offset had incorrect type. so it seems like that bugfix for #158743 created a new bug. This is different than the RHEL4 bug that went from 1.14.x to 1.15.
This doesn't seem to be an acceptable solution since you lose all lastlog data. Are you suggesting that this be done every night before backup? Also, this was working fine with tar-1.15.1-5, it just broke with 1.15.1-7.FC4. The changelog says * Wed Jul 27 2005 Peter Vrabec <pvrabec> 1.15.1-7.FC4 - exclude listed02.at from testsuite * Wed Jul 27 2005 Peter Vrabec <pvrabec> 1.15.1-6.FC4 - A file is dumpable if it is sparse and both --sparse and --totals are specified (#154882) - exclude err.patch, it causes SEGV (#158743) * Fri Apr 15 2005 Peter Vrabec <pvrabec> 1.15.1-5 - extract sparse files even if the output fd is not seekable.(#154882) - (sparse_scan_file): Bugfix. offset had incorrect type. so it seems like that bugfix for #158743 created a new bug. This seems different than the RHEL4 bug that went from 1.14.x to 1.15.
You don't need to do it every night, just once. Lastlog won't increase anymore. The reason that lastlog is so huge on 64bits arch. is #149407. One of tar-1.15.1-5 problems was that it produced bad totals.(#154882) http://lists.gnu.org/archive/html/bug-tar/2005-07/msg00025.html #158743 seems to me have nothing with this problem.
OK, thanks. That works for me.