From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
I am trying to run amflush to write some dumps from disk to tape and amflush is
running endlessly consuming 100% CPU time without writing anything to tape. This
only happens when running amflush by hand, the dumps are written to tape
correctly with the normal amdump run by cron.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Insert a tape
2. su amanda -c "/usr/sbin/amflush Daily"
Actual Results: amflush does not write anything to tape.
Expected Results: amflush should write the dumps to tape.
here is the output of: su amanda -c "/usr/sbin/amflush -f Daily"
[root@bart sbackhausen]# su amanda -c "/usr/sbin/amflush -f Daily"
20030704: found Amanda directory.
20030706: found Amanda directory.
Multiple Amanda directories, please pick one by letter:
Select directories to flush [A..B]: [ALL] a
Today is: 20030707
Flushing dumps in 20030704 to tape drive "/dev/nst0".
Expecting tape Daily-4 or a new tape. (The last dumps were to tape Daily-3)
Are you sure you want to do this [yN]? y
amflush: datestamp 20030707
driver: pid 1677 executable driver version 2.4.3
driver: send-cmd time 0.098 to taper: START-TAPER 20030707
driver: adding holding disk 0 dir /var/spool/amanda size 94368540
taper: pid 1678 executable taper version 2.4.3
taper: page size is 4096
taper: buffer size is 32768
taper: buffer at 0x400e2000
taper: buffer at 0x400ea000
taper: buffer at 0x400f2000
taper: buffer at 0x400fa000
taper: buffer at 0x40102000
taper: buffer at 0x4010a000
taper: buffer at 0x40112000
taper: buffer at 0x4011a000
taper: buffer at 0x40122000
taper: buffer at 0x4012a000
taper: buffer at 0x40132000
taper: buffer at 0x4013a000
taper: buffer at 0x40142000
taper: buffer at 0x4014a000
taper: buffer at 0x40152000
taper: buffer at 0x4015a000
taper: buffer at 0x40162000
taper: buffer at 0x4016a000
taper: buffer at 0x40172000
taper: buffer at 0x4017a000
taper: buffer structures at 0x40182000 for 240 bytes
reserving 9436854 out of 94368540 for degraded-mode dumps
Yes, I've seen this also. Note that running in the foreground with
'su amanda -c "/usr/sbin/amflush -f Daily" ' works properly. If you need to run
disconnected, a quick and dirty workaround is to use the 'screen" facility to
run in the foreground in a screen window that you can disconnect.
I've had a look into the archives of the amanda mailinglists and saw some
similar reports. It seems there is a problem with RHs amanda 2.4.3 rpms. I
compiled amanda-2.4.4p1 rpms based on RHs spec file for 2.4.3 and the problem
disappeared. Maintainer, pls update the rpms to 2.4.4p1 or later.
Just checked, and the Rawhide RPMs are already 2.4.4p1. I will be testing them
over the next few days, but if you are correct, then that should close this bug.
I rebuilt the Fedora Core SRPM for 2.4.4.p1 under RHL 9 and updated my
backup server. After updating, I am able run amflush without it
pegging the cpu at 100% and never writing to tape.
Sorry, I should have reported back. The 2.4.4p1 RPMS fixed this for
me under RH9. They continue to work fine under Fedora.