I do have VERBOSE = 5 in bp.conf and vm.conf, plus the following empty
files to increase debug messages:
/usr/openv/volmgr/AVRD_DEBUG - More avrd logging in /var/adm/messages
/usr/openv/volmgr/ROBOT_DEBUG - More robot messages
/usr/openv/volmgr/DRIVE_DEBUG - More drive information logging
/usr/openv/volmgr/LTID_DEBUG - More ltid information logging
/usr/openv/volmgr/database/DEBUG - More ltid logging
And the following debug directories (similar to the directories in
netbackup/logs):
/usr/openv/volmgr/debug/daemon/
/usr/openv/volmgr/debug/reqlib/
/usr/openv/volmgr/debug/ltid/
/usr/openv/volmgr/debug/tpcommand/
Justin
Greenberg, Katherine A wrote:
> Set your VERBOSE = 5 in vm.conf not in bp.conf for starters...
>
> Also, are you starting ltid with a -v option? It might give you some
> more info since it's logging to /var/adm/messages like that.
>
> ~Kate
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> Katherine Greenberg
> Systems Engineer
> Mid-Range Storage Management
> Aetna, Inc.
> greenbergka AT aetna DOT com
> Work: 860.636.6724
> Pager: 860.366.0672
>
>
>
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Justin C.
> Lloyd
> Sent: Monday, April 12, 2004 11:50 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] tape eject failing after backups
>
>
> I have a case open with Veritas (and Spectra Logic) on this, but so far
>
> we haven't come up with anything and I'm getting desperate.
>
> I have a Spectra Logic 2K with 15 slots and 2 AIT-3 drives, and I'm
>
> using NetBackup Datacenter 4.5 on Solaris 9 (64-bit). Things have been
>
> running relatively fine, but about a week ago I would come in to find
>
> that the catalog backups had not started because the two drives were
>
> still occupied with tapes from backups. The backups had completed but
>
> the tapes fail to eject. It looks like they're trying to, because they
>
> start moving towards the drive doors, but then settle back in. This
>
> repeats for about 30 seconds and then stops. The ONLY way to get the
>
> tapes out is to physically remove the drives from the library and
>
> manually extract the tapes. This happens EVERY time NBU tries a backup.
>
> Now, if I use robtest, I can move tapes in and out of drives with no
>
> problem. I cannot, however, use robtest to remove tapes inserted by
>
> NBU. According to Veritas, NBU removes the tapes from the drives using
>
> tpunmount, which uses /usr/bin/mt, which uses the OS SCSI tape driver,
>
> /kernel/drv/st. On the other hand, robtest uses Veritas' generic SCSI
>
> driver, /kernel/drv/sg.
>
> Now the *really* strange thing is that I can insert a tape with robtest
>
> and remove it with mt.
>
> Note that the tapes are not *physically* stuck/jammed in the drives. I
>
> can manually unload them without difficulty. So it would seem that
>
> something about how NBU is mounting the tapes is causing this.
>
> Everything used to work fine, this just started happening one day. I
>
> have replaced hardware a couple of times before this started, but that
>
> was generally due to actually hardware failures. I just installed a new
>
> library last Monday, but that had no effect on the problem.
>
> I've set VERBOSE = 5 in bp.conf and added some touch files under
>
> /usr/openv/volmgr for more logging output, but the Veritas engineer has
>
> yet to find something.
>
> Anyone have any thoughts on this?
>
> Justin
>
> --
>
> Justin C. Lloyd
> Unix System Administrator
> MCI System Technology Solutions
> Office 703.886.3219 Vnet 806.3219
>
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
> This e-mail may contain confidential or privileged information. If you
> think you have received this e-mail in error, please advise the sender by
> reply e-mail and then delete this e-mail immediately. Thank you. Aetna
>
--
Justin C. Lloyd
Unix System Administrator
MCI System Technology Solutions
Office 703.886.3219 Vnet 806.3219
|
