FYI, it finally finished, I just let it stay there and it got hung on another
node, I waited and it finally completed. Thanks for the suggestion.
Philip
James Shanks <James_Shanks@TIVOLI.COM> on 11/30/99 12:27:17 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: Philip Guerra/Tivoli Systems)
Subject: Re: ovtopofix is hanging
One more thing and perhaps a first to check -
Are ovtopmd and ovwdb still running? Do ovstatus to make sure. If one of them
dies in the middle of your ovtopofix, then that could hang it.
James Shanks
Tivoli (NetView for UNIX) L3 Support
---------------------- Forwarded by James Shanks/Tivoli Systems on 11/30/99
01:26 PM ---------------------------
James Shanks <James_Shanks@TIVOLI.COM> on 11/30/99 01:19:59 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: ovtopofix is hanging
Did you ovstop netmon before running ovtopofix? If not, do it now. Ditto with
all your map GUIs. Basically this would indicate a database integrity problem I
think and a very serious one.
I haven't heard of anything like this before. There are only two courses of
action at this point. To determine why (or at least where) ovtopofix is hanging
you would need to obtain a diagnostic program called gdbprof from Tivoli NetView
Support and run that. It runs gdb and gets a snapshot of the call stack of an
attached program. If you already have gdb, of course, you could do it yourself,
(issue "stack info" after attaching to the ovtopofix process), but sooner or
later, you will have to call Support to pursue this. And in fact, if ovtopofix
problems have occurred for other Solaris users, they would know.
Your other course of action is to decide not to pursue the hang right now and
kill ovtopofix. Then try running it again. If it hangs again, you definitely
have database problems and you may have to restore from a backup (assuming you
have one) or clear your entire databases and let everything get re-discovered.
As an interim step you can start the GUI and try to delete the entire object
which seems to be causing the problem. Locate this bp5-5000-rsm on the map and
delete from all submaps. Then open your other maps and do the same thing. Then
close the GUI and run ovtopofix -a again and see if things improve. Your can
add the main (loopback) interface to the netmon seed file so that bp5-5000-rsm
gets re-discovered as quickly as possible once he has been fully removed.
Good luck, I think you will need it.
And call Support sooner or later, as this is not normal behavior
James Shanks
Tivoli (NetView for UNIX) L3 Support
Philip_Guerra@TIVOLI.COM on 11/30/99 12:44:07 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: ovtopofix is hanging
I am running NetView for Unix 5.1.2 on an Ultra 10 running Solaris2.7. I
proceeded to do an "ovtopofix -a" as a weekly maintenance task. It started to
clean up stuff and it got to this point (see below) and is hung. Any ideas?
bp5-5000-rsm:xxx.xxx.xxx.xxx (28886) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (28888) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (28916) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (28917) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (29061) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (29177) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (29178) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (29179) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (29182) -- removed and not in any maps, deleting
bp5-5000-rsm:xxx.xxx.xxx.xxx (29187) -- removed and not in any maps, deleting
Updating bp5-5000-rsm (objid = 1067)
BTW, I replaced the actual IP address with the xxx.xxx.xxx.xxx and it was the
same address for every line.
It is still in a hung state.
Regards,
Philip
|