Every night, OB starts up a process that connects the backup device (StorageTek silo) via SCSI on a secondary system (not the OB system itself). The backups are working okay, but the uma is not dying at the end of the process. As a result, we have UMAs running from several days ago.
I can certainly kill the process with no apparent ill-effects, but what I'd like to understand is why the uma process continues to run in the first place. What is it waiting for that it doesn't get? Again, the backups seem to be running just fine ...
I'm at PHSS_19939 on the CS (not 20084), and PHSS_18681 (not 21334) but there didn't seem to be anything related in the patch descriptions to our particular problem. Otherwise the patches look pretty current.
Look for something non-standard - like the use of an alternate shell for ROOT, or perhaps name resolution problems.
From the command prompt of the machine in question can you start and stop UMA without any problems?
./uma -ioctl /dev/robotic --replace /dev/robotic with the path for your scsi changer file..
Try starting and stopping it several times - look for delays...
Remember that applying the patches to the cell server isn't the whole story...the patch also must be pushed from the cell server (or depot server) out to where the (MEDIA) agent is installed...it is easy to forget this step - so try re-pushing the media agent.
Is this a new symptom after patching or upgrades? Try and identify what changed.
On some systems we can have problems with the automatically installed SCHGR (/dev/rac/...) drivers - consider using SCTL (or SPT -depending on the hardware configuration...)
Look in /var/opt/omni/log/debug.log for hints as to what might have glitched.
Is this a SAN/storage area network?- you have to be careful configuring these.
Do you have one tape library defined multiple times within Omniback? Be sure and use LOCK NAMES and configure things carefully.
Is it a supported tape drive or library? Has firmware changed? If you upgraded - is it STILL supported?