cancel
Showing results for 
Search instead for 
Did you mean: 

Getting an error code 278 "unable to collect pre eject information from the API robot" on vault ejects

C_J_Hund
Level 4
Certified

Hi All,

I'm getting an error "278:unable to collect pre eject information from the API robot" when running my vault eject policy.  I know I've seen this before, and I believe last time the problem had something to do with a lock file on the robot that was stashed away somewhere under /usr/openv/volmgr.  I don’t see anything obvious in the vault log.  Has anyone bumped into this before?

Sincere thanks,
C.J.

 

1 ACCEPTED SOLUTION

Accepted Solutions

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Just delete the EJECT file.
We had something similar at a customer recently - error message was a bit different (can't remember exact error, was neither 251 nor 278, but ejects were failing).

This TN had the answer:
http://seer.entsupport.symantec.com/docs/271695.htm

Troubleshooting:
Check to make sure that another administrator is not also trying to eject taps to the MAP.  If another eject is in progress then a Status 251 will be returned as part of normal NetBackup operations.

If another eject is not occurring, then check to make sure the lock files were properly cleaned up from the last eject.  These files can be found on the robot control host listed in the profile.  It will be necessary to check for any EJECT*.txt files in the /usr/openv/volmgr/misc directory on UNIX systems or the <install_dir>\Volmgr\misc directory on Windows systems.

View solution in original post

5 REPLIES 5

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

You did not mention what kind of API robot?
If ACSLS, look for EJECT*.txt files under /usr/openv/volmgr/misc

C_J_Hund
Level 4
Certified
This is an ACS robot.

In that /usr/openv/volmgr/misc directory, I do have a number of .lock files:
****** # ls -l *.lock
-rw-------   1 root     root          14 May 18 08:41 acssel.lock
-rw-------   1 root     root           0 Nov  1  2008 lmfcd.lock
-rw-------   1 root     root           0 Nov  1  2008 tl8cd.lock
-rw-------   1 root     root           0 Nov  1  2008 tldcd.lock
-rw-------   1 root     root           0 Nov  1  2008 tlhcd.lock
-rw-------   1 root     root          17 May 18 08:40 vmd.lock

Pluse, I do have on EJECT* file:
****** # ls -l *.txt
-rw-------   1 root     root        2048 May  5 15:46 EJECT_0_1_0_0.txt

Is that EJECT file the source of my problems?  The date stamp on that file (May 5th) is the date that the problems with ejects began.  Can we just delete that file?

Sincere thanks,
C.J.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Just delete the EJECT file.
We had something similar at a customer recently - error message was a bit different (can't remember exact error, was neither 251 nor 278, but ejects were failing).

This TN had the answer:
http://seer.entsupport.symantec.com/docs/271695.htm

Troubleshooting:
Check to make sure that another administrator is not also trying to eject taps to the MAP.  If another eject is in progress then a Status 251 will be returned as part of normal NetBackup operations.

If another eject is not occurring, then check to make sure the lock files were properly cleaned up from the last eject.  These files can be found on the robot control host listed in the profile.  It will be necessary to check for any EJECT*.txt files in the /usr/openv/volmgr/misc directory on UNIX systems or the <install_dir>\Volmgr\misc directory on Windows systems.

C_J_Hund
Level 4
Certified
That worked.  Thank you very much for your help, Marianne!

C.J.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Glad I could help.
If you don't mind - please mark the post that answered your question as solution?