List,
Turns out that the problem was happening because the ruleset zacchi.rs was listed in the ESE.automation file. Although the ruleset has 'forward' statements in it, it worked for a while before stopping.
I will wait a few more days before closing the PMR, but it's been working fine for almost 3 days now.
Best regards,
Marcelo
On 7/30/07, Leslie Clark
<lclark@us.ibm.com> wrote:
What valid ruleset do you have in ESE.automation?
I only ask in case you are trying to forward to TEC via ESE.automation.
To be clear, and sorry if you already go this right, but
1) nvserverd forwards to TEC based
only on tecint.conf, and the rule it uses must have 'forward' statements
in it.
2) rules in ESE.automation must NOT
have 'forward' statements in it.
Cordially,
Leslie A. Clark
IT Services Specialist, Network Mgmt
Information Technology Services Americas
IBM Global Services
(248) 552-4968 Voicemail, Fax, Pager
James,
Thanks for you help!
The event window freezes exactly the same time as the nvserverd log, and
if I close it or restart the nvserverd daemon nothing happens. I have to
make a full stop/restart daemons for the system to return to full operation.
There are no queues shown in netstat -a.
About the ESE.automation, only the valid ruleset is listed in the file.
nvtecia -stop and -reload did not restore the event flow, although I did
receive a message in nvserverd regarding the adapter restart:
07/30/2007 08:53:39 AM Close of TEC API requested.
07/30/2007 08:53:39 AM TEC_ITS_BASE;source=nvserverd;origin=10.96.1.13
;hostname=xxxxxxxx.com.br
;adapter_host=xxxxxxxx.com.br
;date="07/30/2007
08:53:39 AM";status=OPEN;severity=FATAL;msg="nvserverd is ending";END
07/30/2007 08:53:39 AM Shutdown Event sent
07/30/2007 08:53:39 AM nvcorrd session closed
07/30/2007 08:53:39 AM TEC handle destroyed
07/30/2007 08:53:39 AM Close of TEC API completed.
07/30/2007 08:54:15 AM Restart of TEC API requested.
07/30/2007 08:54:15 AM Reading tecint.conf parameters:
07/30/2007 08:54:15 AM NvserverdTraceTecEvents = YES
07/30/2007 08:54:15 AM fallbackClass = TEC_ITS_BASE
07/30/2007 08:54:15 AM ServerLocation = @EventServer
07/30/2007 08:54:15 AM Java Options = -Xusealtsigs
07/30/2007 08:54:15 AM NvserverdPrimeTecEvents = (null)
07/30/2007 08:54:15 AM NvserverdSendSeverityTecEvents = (null)
07/30/2007 08:54:15 AM TecRuleName = zacchi.rs
07/30/2007 08:54:15 AM TecConnServer::openSession( ) with nvcorrd:
07/30/2007 08:54:15 AM fRuleName = zacchi.rs, CorrelationType = 1, priming_flag
= 1, TivoliTEC = 1
07/30/2007 08:54:15 AM TEC_ITS_BASE;source=nvserverd;origin=10.96.1.13
;hostname=
xxxxxxxx.com.br;adapter_host=xxxxxxxx.com.br
;date="07/30/2007
08:54:15 AM";status=CLOSED;severity=HARMLESS;msg="nvserverd has
connected using rule zacchi.rs";END
Beyond that, nothing else is logged on the file and no events are forwarded
to TEC.
I am already in contact with IBM support but, still, if anyone has any
idea, I am open minded.
Best regards,
Marcelo
On 7/27/07, James Shanks <jshanks@us.ibm.com
>
wrote:
Please try not to make as fool of me. One cannot make
a remote diagnosis if one does not have all the facts. The hung event window
was an important piece of information which you left out the first time.
But it remains true that once an event is given to the TEC interface nvserverd
has no knowledge of it.
This forum is not a substitute for Level 2, I can only advise you on what
steps I might take to try to narrow down the problem. But I have not seen
this hang issue here.
Is the event window frozen at the same place as the nvserverd.log? If you
close it, do events start flowing to TEC? If you do a netstat -a do you
see send and receive queues backed up? If you open a new event window is
that also hung? Are there other rulesets running in the background via
ESE.automation? Have you tried using nvtecia -stop and stopping the TEC
flow to see whether the events windows start flowing again?
Perhaps there is a daemon problem, though none of our SuSe Linux systems
show such an issue here and the fact that it is isolated to just one machine
makes it even less likely that it is a code bug. If all else fails, then
the only thing I can think of is to obtain (1) a debug nvserverd from NetView
L2, and then (2) run a diagnostic tool they can also give you called gdbprof.
If nvserverd is hung somewhere, then that will show conclusively that it
is. But it will not tell you what to do about it. That may take more diagnosis
and trial-and-error.
Hope this helps. Best I can do.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
"Marcelo Zacchi" < mzacchi@gmail.com
>
James,
The fact that the "Current Events" window also freezes also does
not indicate a problem with the daemon?
On 7/27/07, James Shanks <
jshanks@us.ibm.com> wrote:
All nvserverd does is format the message and give it to
the TEC adapter (EEIF) library functions. The code provided by TEC does
the sending. Once nvserverd passes a formatted message along to TEC, he
is ignorant of what happens to it. If you see it logged in the nvserverd
log, and not followed by an error message, then the hand-off to the TEC
library went smoothly. If it works for a while and then stops, that is
a TEC issue and not a NetView one.
You will need to get a TEC EEIF trace and let TEC support tell you what
is happening. NetView has no way of knowing. NetView L2 can help you enlist
the aid of TEC support but that is all.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
"Marcelo Zacchi" < mzacchi@gmail.com
>
James and Praveen,
I am having the exact same problem on my Linux box.
I have disable the state correlation but it didn't work. I have been exchanging
traces and logs with the IBM support but, until now, no conclusion has
been reached.
The funniest thing is that it appears to 'last' for approximately 12 hours
and then it simply stops. The nvserverd.log only brings messages of successful
operations, no error messages whatsoever.
I have installed FixPack 1 too, but that did not solve the problem.
I am running NV on a SUSE LINUX Enterprise Server 9 (x86_64), but I have
a environment that is just like this one and does not have any problem
with nvserverd.
Has anyone been able to solve or workaround this?
Best regards to all,
Marcelo Zacchi
Siemens SIS NOC LATAM
On 12/13/06, James Shanks <
jshanks@us.ibm.com > wrote:
Have you tried anything to isolate the problem? Is your
TEC cache file growing? Then the TEC code is having problems talking to
your TEC library.
Are events still being written to the nvserverd.log? If you don't have
one then modify your tecint.conf file by uncommenting the line which says
#NvserverdTraceTecEvents=YES.
If the nvserverd.log shows that events are not being sent to TEC, then
you can try turning off State Correlation in tecint.conf. Make it say UseStateCorrelation=NO.
If that solves the problem then most likely you have a java issue.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
"Praveen Kumar" < Praveenkumar.nair@ustri.com
>
Hi All,
I am running NetView 7.1.5 (upgraded from 7.1.4) on Linux, I have the events
forwarded to TEC. After the upgrade nvserverd seems to getting halted (but
the status shows running) no events are forwarded until a restart of the
nvserverd daemon.
Would anyone please help me?
True regards,
Praveen Kumar._______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal
IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal IBM'ers
only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal
IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal IBM'ers
only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|