Possibly nothing, but who knows? My concern about ipmap is that he needs to
write out the last map close time to the map database when he quits. Hopefully
he is getting that done before your problem occurs. If not, then over time, you
map synch times will just get longer and longer and longer.
But if you are going to kill the associated apps which are still running by
reopening the GUI anyway, then it should not hurt them to be killed by a cron
job. The only concern I have is that this may make the debug job more difficult
because then you cannot tell if they would ever go away on their own, or if the
one that is hanging from last night is in the same loop as the one from this
morning. You'll just have to deal with that when the time comes.
If you have run dbxprof before, then I would do it now for these apps. If not,
don't worry about it, because that's what Level 2 will have you do. You ftp it
from them if you don't have it.
How long has this been going on? What level of AIX do you have? Made any
system changes lately?
James Shanks
Tivoli (NetView for UNIX) L3 Support
Rob Napholz <tel1rxn@NJCMAIL.UPS.COM> on 10/12/99 05:02:10 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: closing the map + ipmap
Thanks James
I will try the export command
I have also increased the timeout from 2 to 3 min when closing the map
What are the effect both good and bad of running
/usr/OV/bin/nv6000_smit OVWAPPINITSTOP
from the crontab every morning
SHANKS@TIVOLI.COM wrote:
>
> Well, I have seen a similar problem, but not on any recent version of AIX.
Mine was back in the time that 4.1.5 was current.
>
> The problem then was that AIX was making the application wait while it
released both the paging space on the disk as well as
> the storage in memory when you did a free, and ipmap has a lot of stuff to
free when he finishes. The solution then was to
> export an environment variable, which told AIX not to do that, BEFORE we
started the GUI.
>
> You could try that. Stop all your GUIs, export NODISCLAIM=true , and then
issue netview from the same window. After
> the map synchronizes, close it and see whether ipmap goes way quickly or not.
If it doesn't, then it is time to call
> Support, because you'll need to run traces to find out what ipmap doing. From
what you posted, it looks like ipmap is not
> the only one, either, which makes me think this is a system thing and not
really a NetView thing.
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
>
> Rob Napholz <tel1rxn@NJCMAIL.UPS.COM> on 10/11/99 02:44:41 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: closing the map + ipmap
>
> Has anyone seen this problem ?
>
> When closing the map(file exit) ipmap does not die.
>
> ps -aef |grep tel1rxn
> tel1rxn 26916 1 82 14:22:11 - 7:50 /usr/OV/bin/ipmap
>
> >nv6000
> WARNING: One or more processes are incorrectly parented.
> PID PPID COMMAND
> 17174 1 collmap
> 26916 1 ipmap
> 29978 1 ipmap
> 30344 1 collmap
> Run the following as root user to try to correct the problem.
> /usr/OV/bin/nv6000_smit OVWAPPINITSTOP
>
> If root or the users starts netview, netview will stop/kill ipmap
> causing it to core dump ?
>
> So why isnt ipmap stopping when the map is closed ?
>
> Thanks Rob
|