Well, I do set NVMAPGLOBALACK, so that acknowledgements will be
shared and stored. I don't see what that has to do with things getting
acknowledged all by themselves. I sat there the other night and watched my
'Problem Interfaces' smartset with dozens of interfaces in it all flashing
in
waves of red and ack-green until I grabbed them all and unmanaged them.
One local motif session.
I have seen occasional acks that I suspect are users trying out the web
when I am not looking. And when I open the map, I see all of these
acks at once, and events in the trap log to go with them. That appears
to be normal behavior from what I am reading here.
I wonder if a web client user was dialed in from home and was goofing
around greening up the map when I had the waves of them. I wonder
if they acked and unacked a few times, or, since it was slow, sent the
ack request several times. I wonder if it would have stopped on its own
if I had not unmanaged them (Don's case sounds like maybe not), or
if it is possible to set off a chain reaction. Pretty cool....
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Scott
Donohoo/Raleigh To: IBM NetView Discussion
<nv-l@tkg.com>
/IBM@IBMUS cc:
Sent by: Subject: RE: [NV-L] Acknowledged
trap
owner-nv-l@tkg. generated by trapd
com
11/07/01 10:48
AM
Please respond
to IBM NetView
Discussion
Don,
Other than someone sending the trap manually using the event command or
acknowledgedUtil (which does it for you), ovw_binary generates these traps
only if NVMAPGLOBALACK is set. And it looks like ovw generated the traps
in this case. If they had been sent manually, you would also see
"netmon-related Application connected to trapd" in the trapd.log.
Like James said, it only has to be set for one gui's environment. Whether
or not the variable is set at ovw startup is logged in
/usr/OV/log/ipmap.log. You might check there to see if it is reported as
ever having been set at startup. If ipmap.log shows it has never been set
and you still get these traps, you should call support to have it
investigated.
--
Scott Donohoo
Tivoli NetView for Unix/NT L3
James Shanks/Raleigh/IBM@IBMUS
Sent by: owner-nv-l@tkg.com
11/07/2001 10:25 AM
Please respond to IBM NetView Discussion
To: IBM NetView Discussion <nv-l@tkg.com>
cc:
Subject: RE: [NV-L] Acknowledged trap generated by trapd
Don -
First let me say I am sorry about your predicament, but beyond that I am
mystified by what you are saying.
You are correct that these traps do not come from trapd, despite the "T"
source character, because there was no existing source for ovw_binary and
the lead developer said he did not want to create one. That's where he
said they do come from -- ovw_binary.
But your problem description has so many strange aspects that I cannot see
how they fit together. No one else has reported anything like this (I
would have been consulted I am sure) so I hardly know where to begin. I
don't doubt what you are saying -- I am just so puzzled that I hardly know
what else to say.
But is seems to me that someone had to have to global acknowledgement on
at some point for those traps to have been generated. It only takes one
NetView GUI session. Are you sure no operator sets it? Do you never get
these trapd at any other time, except when the operators have gone home?
But even if it was on, and the operator went home, what I don't understand
is how a defunct ovw_binary process could generate the callback equivalent
of an acknowledge event.
If Exceed is the culprit, then I don't know hat to tell you to do, since
this is the kind of screwy behavior which causes us to say that we do not
support environments where it is used (sorry), since we have no control
over it and no idea how it works internally. It doesn't even talk to
NetView directly but to the X-server on your AIX box (could you need
maintenance here?), and NetView itself has no knowledge that it is running
over an emulated session and there is no way for it to tell. Looks the
same to us as local or telnet, and our code is the same. Have you tried
to reproduce the problem in a controlled way, such as setting up an Exceed
session and deliberately killing it? Then you could see if the ovw_binary
process stays around, or if you can halt the behavior by selectively
killing what is left. I have no idea how collmap and dispsub fit in
here. You could acknowledge an object from a collec! ! tion, of course,
but I don't see how collmap could be causing the ACK himself any more than
how ovw_binary could.
I also don't understand about trapd choking and dying, or the file $HOME
system filling up. Even if hundreds of traps are generated, the only
thing that should grow would be trapd.log and he rolls over, as you
indicated, so there should be a maximum size. And if trapd dies, does it
core? Are there error messages in trapd.log? In nettl?
So puzzled I am all but speechless
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Davis, Donald" <donald.davis@firstcitizens.com>
Sent by: owner-nv-l@tkg.com
11/07/2001 08:41 AM
Please respond to IBM NetView Discussion
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc:
Subject: RE: [NV-L] Acknowledged trap generated by trapd
Leslie,
I have searched the archives and cannot find my original post or James
Shanks answer.
I recall that James indicated that the T in the log was bogus. The
developers did not
want to add a new source character for (I think he said) ipmap.
My problem is not solved nor has it gone away. It seems to occur when
operators using eXceed
kill their eXceed sessions and go home, instead of logging out of NetView
properly.
Usually I see incorrectly parented processes, like collmap and dispsub.
I kill -9 them and all returns to normal, if I catch it before $home file
system is full and
my trapd.log rolls over several times and I lose trap data. If I do not
catch it in time, trapd chokes and dies.
It's all down hill from there...
I am usually alerted, before catastrophic failure, by Tivoli DM monitors
watching pageouts and file system utilization.
I plan to build a monitor to detect hung ovw (ovw_binary) sessions and
kill
them.
Best regards,
Don Davis
-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Tuesday, November 06, 2001 10:27 PM
To: IBM NetView Discussion
Subject: RE: [NV-L] Acknowledged trap generated by trapd
Don, I thought you posted the final answer to this one, but I
cannot find it. The archives (new interface, still missing recent
data) also seem to have nothing for those few days. Can you
repeat the answer, or did it mysteriously stop?
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"O'Neill,
Dermott" To: "'IBM NetView Discussion'"
<ONeillD@aetna <nv-l@tkg.com>
.com> cc:
"'donald.davis@firstcitizens.com'"
Sent by: <donald.davis@firstcitizens.com>
owner-nv-l@tkg Subject: RE: [NV-L]
Acknowledged trap
.com generated by trapd
10/02/01 03:00
PM
Please respond
to IBM NetView
Discussion
Hey Don,
I remember the man page for trapd.conf has something about the "status"
field:
"status A single character indicating the status that is to be assigned
to an object when it generates the defined trap:
0 Defaults
1 Unknown
2 Up
3 Marginal
4 Down
5 Unmanaged
6 Acknowledge
7 User1
8 User2"
It looks like a trap that has the status field set to "6" _might_ cause
trapd to generate an "Acknowledged" message - just a guess though....
You can try the following command string to see if there are any status
"6"'s in your trapd file:
awk ' NF >= 7 && $2 ~ /{/ { if ( $7 == "6" ) print $0}'
/usr/OV/conf/C/trapd.conf
Good Luck,
--Dermott
-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Monday, October 01, 2001 11:48 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] Acknowledged trap generated by trapd
I have not seen it. Could there be a ruleset running that
is acknowledging automatically, but something else
(like RFI) is making them green again very fast? Of
course that would indicate that you actually implemented
something and forgot about it....:) Do tell us what it
turns out to be!
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Davis, Donald"
<donald.davis@firstcit To: "IBM NetView
Discussion (E-mail)"
izens.com> <nv-l@tkg.com>
Sent by: cc:
owner-nv-l@tkg.com Subject: [NV-L]
Acknowledged trap
generated by trapd
10/01/01 12:40 PM
Please respond to IBM
NetView Discussion
NetView 6.0.2 AIX 4.3.3
Has anyone else seen these trap messages in trapd.log?
Why is trapd generating them?
I have NO acknowledged symbols in my map.....
Global Acknowledgement option is OFF
Could it be that something is executing /usr/OV/bin/acknowledgeUtil ???
----------------------------------------------------------------------------
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 819
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 977
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 979
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 1012
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 1996
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 2261
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 2263
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 2717
1001952434 7 Mon Oct 01 12:07:14 2001 dcnc.tivoli.aaa.com T default:
Acknowledged 2718
=======================
Donald Davis
First Citizens Bank
Systems Engineer Consultant
Enterprise Management
100 East Tryon Road
Raleigh, NC. 27603-3526
919-716-8448
----------------------------------------------------------------------------
--
This electronic mail and any files transmitted with it are confidential
and
are intended solely for the use of individual or entity to whom they are
addressed. If you are not the intended recipient or the person responsible
for delivering the electronic mail to the intended recipient, be advised
that you have received this electronic mail in error and that any use,
dissemination, forwarding, printing, or copying of this electronic mail is
strictly prohibited. If you have received this electronic mail in error,
please immediately notify the sender by return mail.
============================================================================
==
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|