Vault eject hung

[Mastana420]

Hi

Current environment:

Master server running on Redhat Linux 6 with NBU version 7.6.0.3

ACS robot.

While ejecting the vaulting tapes, the job fails with an error (278: Unable to collect pre eject information from the API).

I have searched through Symantec forums, and tried as suggested in various forum threads, but i am unable to get it to work.

From Admin GUI, when i choose deffered eject to eject the tapes, i clearly see that there is 2 session there, one which is the correct one with all the tapes that needs to be ejected, while there is another session there most probably a stuck job from previous eject: see attachment.

Anyhow, what i have tried so far, is to look for a Eject*.txt file in the following location on my Linux master server: /usr/openv/volmgr/misc

I do not have any eject files there at all. Files i have the are as follows:

bpdbm_upgrade.lock
DqDriveState
lmfcd.lock
ltitables
README
robotic_db
tl8cd.lock  ----> already tried renaming them to resolve the issues, without any luck
tldcd.lock ----> already tried renaming them to resolve the issues, without any luck
tlhcd.lock ----> already tried renaming them to resolve the issues, without any luck
vmd.lock

and alot of acssel.lock files followed by the mediaservername and som sort of number. 13751.

Another issue i have is that, once i try to amment something and give it a go, i have to wait for 2 hours before the job cancels. I have tried the command line as well as GUI to cancel the job, but it just wont do anything, and i end up waiting for approx 2 hours before Netbackup stops the job. Any other way of cancelling it faster?

[Marianne]

Do you have media servers also accessing the ACSLS robot?

If so, check all media servers for Eject*.txt files.

To troubleshoot vault issues, please locate session logs, copy to .txt files and upload as File attachments.

/usr/openv/netbackup/vault/sessions/vault_name/sidxxx/logs

I suggest you start with detail.log.

[Mastana420]

So eject file needs to be cleared from all the mediaservers which has access to robot, either directly or indirectly (through control host)? So with other words, clear all the eject files located on the servers listed under Devices - Robots?

I guess the log file you are refering to, is located on the master server?

By the way, does ACSLS host needs to be cleared aswell? because we have a separate host which controls the ACSLS.

[Marianne]

With ACSLS, there is no 'robot control host' in NBU, which means that any of the media servers could have been used at any point to eject tapes.
This is why all media servers connected to the ACS robot must be searched for the 'Eject' files.
I once saw a similar issue at at Customer site and found the problematic Eject file on the 4th media server that we searched.

Log and eject files look totally different on the ACSLS server - no need to look there.

Yes - vault session logs will be on the master.

[Mastana420]

Oki, i will have a look at the mediaservers, we have plenty of them. I have sent you the log file in private, please see you private innbox.

[Mastana420 · Accepted solution]

we resolved the issue by manually ejecting the tapes from acsls server. Problem with that is that net backup does not get updated, so even running an inventory would fail. Ended up creating a technical support case. We verified that no jobs were running on this particular media server, which also is a master server. Technician restarted the vmps services, some of them had to be killed by "kill -9" option. Then he ran the inventory from the command line. Everything cleared up after that. Now Even from GUI everything is working fine. Send like restarting the vmps services did the Job.