Bug 98665 - amflush consumes 100% CPU time and does not write anything to tape
Summary: amflush consumes 100% CPU time and does not write anything to tape
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: amanda   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-07 09:44 UTC by Sven Backhausen
Modified: 2014-08-31 23:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-07 21:22:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Sven Backhausen 2003-07-07 09:44:37 UTC
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):

How reproducible:

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.

Additional info:

here is the output of: su amanda -c "/usr/sbin/amflush -f Daily"
[root@bart sbackhausen]# su amanda -c "/usr/sbin/amflush -f Daily"
Scanning /var/spool/amanda...
  20030704: found Amanda directory.
  20030706: found Amanda directory.

Multiple Amanda directories, please pick one by letter:
  A. 20030704
  B. 20030706
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[00] at 0x400e2000
taper: buffer[01] at 0x400ea000
taper: buffer[02] at 0x400f2000
taper: buffer[03] at 0x400fa000
taper: buffer[04] at 0x40102000
taper: buffer[05] at 0x4010a000
taper: buffer[06] at 0x40112000
taper: buffer[07] at 0x4011a000
taper: buffer[08] at 0x40122000
taper: buffer[09] at 0x4012a000
taper: buffer[10] at 0x40132000
taper: buffer[11] at 0x4013a000
taper: buffer[12] at 0x40142000
taper: buffer[13] at 0x4014a000
taper: buffer[14] at 0x40152000
taper: buffer[15] at 0x4015a000
taper: buffer[16] at 0x40162000
taper: buffer[17] at 0x4016a000
taper: buffer[18] at 0x40172000
taper: buffer[19] at 0x4017a000
taper: buffer structures at 0x40182000 for 240 bytes
reserving 9436854 out of 94368540 for degraded-mode dumps

Comment 1 Matthew Saltzman 2003-08-09 13:56:39 UTC
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.

Comment 2 Sven Backhausen 2003-08-11 13:08:35 UTC
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.

Comment 3 Matthew Saltzman 2003-08-11 13:42:13 UTC
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.

Comment 4 Sean O'Connell 2003-12-16 02:22:55 UTC
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.

Comment 5 Matthew Saltzman 2003-12-16 03:22:49 UTC
Sorry, I should have reported back.  The 2.4.4p1 RPMS fixed this for
me under RH9.  They continue to work fine under Fedora.

Note You need to log in before you can comment on or make changes to this bug.