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
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.
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.
Heh. Only last night did I add something similar to the script; I'll see how it goes today and let you know.
(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.
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.
Well, haven't noticed a regression in behaviour since installing them, and your patches previously worked, so I think these packages fix the problem.
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