Bug 144052 - amverifyrun sometimes verifies the wrong tapes
amverifyrun sometimes verifies the wrong tapes
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: amanda (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Jay Turner
:
Depends On:
Blocks: 156320
  Show dependency treegraph
 
Reported: 2005-01-03 23:56 EST by Anchor Systems Managed Hosting
Modified: 2015-01-07 19:09 EST (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Anchor Systems Managed Hosting 2005-01-03 23:56:05 EST
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):

amanda-server-2.4.4p1-0.3E

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-24 23:59:25 EST
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 14:28:24 EST
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-23 19:26:38 EST
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-04 20:37:02 EDT
(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 13:15:29 EDT
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 05:11:12 EDT
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 13:35:57 EDT
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.

http://rhn.redhat.com/errata/RHBA-2005-533.html

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