Bug 98665
| Summary: | amflush consumes 100% CPU time and does not write anything to tape | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Sven Backhausen <sbackhausen> |
| Component: | amanda | Assignee: | Jay Fenlason <fenlason> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | jfeeney, mjs, sean |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-06-07 21:22:30 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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): amanda-server-2.4.3-4 How reproducible: Always 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