Highlighted

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

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 Solution

Accepted Solutions
Accepted Solution!

Just delete the EJECT


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
Highlighted

You did not mention what kind


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

This is an ACS robot. In that

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.
Accepted Solution!

Just delete the EJECT


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

Highlighted

That worked.  Thank you very

That worked.  Thank you very much for your help, Marianne!

C.J.
Highlighted

Glad I could help. If you


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