Bug 144052 - amverifyrun sometimes verifies the wrong tapes
Summary: amverifyrun sometimes verifies the wrong tapes
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: amanda (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Jay Turner
Depends On:
Blocks: 156320
TreeView+ depends on / blocked
Reported: 2005-01-04 04:56 UTC by Anchor Systems Managed Hosting
Modified: 2015-01-08 00:09 UTC (History)
2 users (show)

Fixed In Version: RHBA-2005-533
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 17:35:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:533 qe-ready SHIPPED_LIVE amanda bug fix update 2005-09-28 04:00:00 UTC

Description Anchor Systems Managed Hosting 2005-01-04 04:56:05 UTC
Description of problem:

amverifyrun <config> supposedly checks for the most recent dump of
that config, and runs amverify on the tapes that were used in that run.

we run amverifyrun on a config immediately after the amdump has
finished, as part of the same cron job.

However sometimes the wrong tapes are chosen, and there seems to be no
pattern to it; at first I thought it was just an incomplete regex
(i.e. tape labelled ANCHOR11 being verified instead of ANCHOR1 and
vice versa) but I've also seen things like ANCHOR4 be verified two
days consecutively when instead tape 16 and 1 should have been.

Version-Release number of selected component (if applicable):


How reproducible:

frequently, but so far unpredictably.

Steps to Reproduce:
1. amdump config && amverifyrun config
Actual results:

not-most-recent tape is verified

Expected results:

most recent tape is verified

Comment 1 Anchor Systems Managed Hosting 2005-01-25 04:59:25 UTC
I had a look at amverifyrun, and the errant line is:

FIRST_SLOT=`grep "taper: slot" $AMLOG | sed 1q | sed 's/://g' | awk
'{print $3}'`

this gives results such as:

[root@ark root]# grep "taper: slot" /var/lib/amanda/anchor/amdump.1
taper: slot 7: date 20050115 label ANCHOR5 (active tape)
taper: slot 8: date 20041212 label MAPINFO4 (no match)
taper: slot 1: date 20050112 label ANCHOR15 (exact label match)

and thus uses tape ANCHOR5, which is incorrect; the tape that was
dumped to was ANCHOR15.

So I suspect the error is caused by the grep, the first taper line
isn't necessarily the tape that was dumped to.

Comment 2 Jay Fenlason 2005-02-23 19:28:24 UTC
What happens if you change FIRST_SLOT= line to read 
FIRST_SLOT=`grep "taper: slot" $AMLOG | fgrep 'exact label match 
new tape 
first labelstr match' | sed 1q | sed 's/://g' | awk '{print $3}'` 
Yes, that's three lines.  This has it use the first slot line that contains 
the text taper uses when it's found a tape to write to. 
Unfortunatly, I don't have a tape changer, so I can't test this fix myself. 

Comment 3 Anchor Systems Managed Hosting 2005-02-24 00:26:38 UTC
Heh.  Only last night did I add something similar to the script; I'll see how it
goes today and let you know.

Comment 4 Anchor Systems Managed Hosting 2005-04-05 00:37:02 UTC
(In reply to comment #3)
> Heh.  Only last night did I add something similar to the script; I'll see how it
> goes today and let you know.

D'oh, just realised I didn't get back to you.

Your modifications work great, it hasn't picked the wrong tape since.

Comment 5 Jay Fenlason 2005-05-02 17:15:29 UTC
I've put test rpms of amanda*-2.4.4p1-0.3E.1.{src,i386}.rpm up on 
http://people.redhat.com/fenlason/.amanda/  Please try them out and report 
whether they fix this problem. 

Comment 7 Anchor Systems Managed Hosting 2005-05-06 09:11:12 UTC
Well, haven't noticed a regression in behaviour since installing them, and your
patches previously worked, so I think these packages fix the problem.

Comment 11 Red Hat Bugzilla 2005-09-28 17:35:57 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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