On Fri, 24 May 2002, Niall O Broin wrote: > On Fri, May 24, 2002 at 03:23:02PM +0200, Ulrik Sandberg wrote: > > > > What happens if you eject and then forget to switch tapes? Like in: > > > > amdump && amverify ; mt -f /dev/rmt/1n offline > > > > I think amverify prompts for a tape and then just sits there. This might > > affect the following amdump in a bad way. Processes already running and > > such. > > Indeed it does. I had a situation (public holiday) where the tape wasn't put > in for the backup. So the dumps happened to the holding disk - no problems > so far. But then amverify was run (from my backup script). It found no tape > and just sat there. The next day I inserted a tape to run amflush. Of course > amverify saw the tape but knew that it wasn't what it wanted so exited with ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^ > an error and then the script ejected the tape. Then of course amflush failed > because there was not tape in the drive when it went looking for it :-)
You state above that amverify exited with an error. It probably didn't fail because it was the wrong tape. As has been pointed out to me in private mail: amverify will happily verify old tapes as well, of course. All it does is check that the tape and its contents is readable, not that it is "the right tape". > I normally manage the office in question from > 1000 km away - fortunately I > was present when all this rigmarole happened, otherwise it might have been > quite confusing. Next thing was to edit my script to do an 'mt status' and > check the return code and only run amverify if it appears that there is a > tape. Yes. So my point still remains: If you eject the tape and forget to put in an new tape, then amverify will "hang" forever, waiting for a tape. It will most likely affect the following amdump. It could be solved with a wrapper around amverify, as Niall did. Another solution would be to build the check into amverify and enable it with a flag, like --exit-if-no-tape. -- Ulrik Sandberg
