Error E-unk-000-000 Failed To Make A Connection To Server

row; probe disconnect; results processing failed Technote (troubleshooting) Problem(Abstract) The error "ERROR=Attempt to insert duplicate row on line 1 of statement" , what does this mean in the probe log? Why does the probe repeatedly disconnect and reconnect? Symptom 2012-04-30T08:40:31: Error: E-UNK-000-000: Server 'NCOMS': ERROR=Attempt to insert duplicate row on line 1 of statement 'insert into custom.status values ( 'DS=2-0-2-1-2-3-2',0,'NODE','10.10.10.10','mttrapd','SNMP probe','DS=2-0-2-1-2-3-2','',1,'DS alert with 1 entities affected.',0,1335793231,1335793231,0,0,1,0,4100,0,'',65...' 2012-04-30T08:40:31: Warning: W-UNK-000-000: Results processing failed 2012-04-30T08:40:31: Error: E-UNK-000-000: Connection to object server 'NCOMS' marked DEAD ! 2012-04-30T08:40:31: Debug: D-UNK-000-000: SAF: Writing DisconnectionTime file for NCOMS 2012-04-30T08:40:31: Debug: D-UNK-000-000: Attempting a connection to server 'NCOMS'. Resolving the problem The duplicate row error will cause the probe to disconnect and reconnect to the Object Server. If the probe is inserting into the alerts.status table, check that the default trigger deduplication exists and is enabled. To prevent the error and the probe disconnection for other tables than alerts.status, a deduplication trigger should be written for the custom table on what action to take when there is a duplicate row. Below is an example which simply drops the incoming duplicate event data and make no updates. This will prevent the probe disconnections, but you may want to update the trigger to take a different action when the duplicate row is received. If the duplicate event data is really needed, either the probe rules file can be updated to make the Identifier unique or the trigger updated to update the existing row in the custom table. create or replace trigger custom_dedup group default_triggers debug false enabled true priority 1 comment 'Deduplication processing for custom.status' before reinse

config 5 replies Latest Post - ‏2010-04-08T10:02:24Z by SystemAdmin Display:ConversationsBy Date 1-6 of 6 Previous Next SystemAdmin 110000D4XK 1283 Posts Pinned topic Probe Server config ‏2010-04-06T16:12:30Z | Tags: Answered question This question has been answered. Unanswered question This question has not been answered yet. We are just getting started and need some assistance. We decided to use a seperate server for our probe server (as others have suggested) but http://www-01.ibm.com/support/docview.wss?uid=swg21622825 cannot find any documentation specific for installing/configuring a probe server. What we've done so far on our "probe" server is run the basic ./install.bin but used the customized install and only installed "Probe Support". We then installed the Simnet probe, uncommented the simnet.props file, pointed the Server parameter to https://www.ibm.com/developerworks/community/forums/thread.jspa?threadID=324422 our ObjectServer and started the probe. The following errors are recorded in the simnet.log: 2010-04-06T11:54:29: Error: E-UNK-000-000: ct_connect(): directory service layer: internal directory control layer error: Requested server name not found. 2010-04-06T11:54:29: Error: E-UNK-000-000: Failed to make a connection to server 'OMNIOST1'. 2010-04-06T11:54:29: Error: E-UNK-000-000: Failed to connect to all required ObjectServers. 2010-04-06T11:54:29: Error: E-UNK-000-000: Failed to read rules - aborting What are we missing? Do we need to install other things on the probe server? Im not understanding how the probe knows about our ObjectServer and think this is probably the problem. Im sure this is something silly that we didnt do. Any help appreciated. Thanks Jab Log in to reply. Updated on 2010-04-08T10:02:24Z at 2010-04-08T10:02:24Z by SystemAdmin SystemAdmin 110000D4XK 1283 Posts Re: Probe Server config ‏2010-04-06T16:28:49Z This is the accepted answer. This is the accepted answer. You need to define the ObjectServer hos

[ thread ] [ subject ] [ author ] Thanks Alex, yes the server is in secure mode - and I thought I had configured the probe correctly, but will do that again. --Geff --- On Thu, 2/17/11, Alex Greenbank https://netcoolusers.org/archives/users/2011-February/061808.html wrote: From: Alex Greenbank Subject: Re: [INUG-Users] Failed to initialise To: users at netcoolusers.org Date: Thursday, February 17, 2011, 8:15 AM Hello, Gah, remembered something just as I hit submit. https://netcoolusers.org/archives/users/2013-August/071186.html The "No error" bit is coming from the Sybase transport layer as that's a logged by an Open/Client callback, so that means it's nothing specific to the Open Client/Server code. So, my guess would be that error e-unk-000-000 the ObjectServer is in Secure mode and that the probe hasn't been setup with appropriate AuthUsername and AuthPassword properties, and so the ObjectServer is rejecting the connection. The ObjectServer logfile should contain more info. Also explains why nco_ping and nco_sql work since they handle secure mode differently to probes (nco_ping by being able to bypass secure mode, but being kicked off straight after connecting, and nco_sql because you're supplying the appropriate user error e-unk-000-000 failed credentials). If this is the case then the error messages output at the probe could probably do with being updated to contain something more useful. Ta, -Alex users-bounces at netcoolusers.org wrote on 17/02/2011 12:53:21: > From: Alex Greenbank/UK/IBM at IBMGB > To: users at netcoolusers.org > Date: 17/02/2011 12:55 > Subject: Re: [INUG-Users] Failed to initialise > Sent by: users-bounces at netcoolusers.org > > Hello, > > No, probes don't use IDUC. > > This is the snippet to look at, the rest is just follow-on fluff from the > original message (this really should be cleaned up so we don't log so many > messages for a single error). > > 2011-02-15T13:44:34: Debug: D-UNK-000-000: Attempting a connection to > server 'NCOMS_T'. > 2011-02-15T13:44:35: Error: E-UNK-000-000: Server 'NCOMS_T': No error > 2011-02-15T13:44:35: Error: E-UNK-000-000: ct_connect(): protocol specific > layer: external error: The attempt to connect to the server failed. > > Although "No error" is rather useless/zen. > > Anything in the log file for NCOMS_T, it could be something like you've > reached your connection limit on the ObjectServer or similar. > > Put NCOMS_T in debug during the connection attempt if necessary. > > Ta, > > -Alex > > > users-bounces at netcoolusers.org wrote on 17/02/2011 12:42:12: > > > From: "Schern

[ date ] [ thread ] [ subject ] [ author ] William, The props file seems ok, pointing to the right places. I have this error on the mttrapd.log: 2013-08-06T10:48:12: Information: I-UNK-000-000: Connecting ... 2013-08-06T10:48:12: Debug: D-UNK-000-000: Shutting down Probewatch heartbeat thread. 2013-08-06T10:48:12: Debug: D-UNK-000-000: Probewatch heartbeat thread is already shutdown. 2013-08-06T10:48:12: Debug: D-UNK-000-000: Stopping separate communications threads if they are running. 2013-08-06T10:48:12: Debug: D-UNK-000-000: Running with single threaded communications. 2013-08-06T10:48:12: Debug: D-UNK-000-000: Reading /opt/IBM/tivoli/netcool/omnibus/etc/rules/snmptrap.rules 2013-08-06T10:48:12: Debug: D-UNK-000-000: Plain text rules file detected. 2013-08-06T10:48:12: Error: E-UNK-000-000: Rules file '/opt/IBM/tivoli/netcool/omnibus/etc/rules/snmptrap.rules' line 119: Failed to read lookup table file '$NC_RULES_HOME/include-snmptrap/CorrScore.snmptrap.lookup' 2013-08-06T10:48:12: Information: I-UNK-000-000: Falling back to previous rules file. 2013-08-06T10:48:12: Error: E-UNK-000-000: Failed to read rules: error in rules file 2013-08-06T10:48:12: Error: E-P_M-102-000: Failed to initialise session: Opl library error (see previous messages) ...and here is line 119 from the snmtrap.rules file: table snmptrapCorrScore = "$NC_RULES_HOME/include-snmptrap/CorrScore.snmptrap.lookup" I´ve checked and this file exists and is in this exact path....so, what could be wrong? Thanks Mario ________________________________ From: William Cain To: users at netcoolusers.org Sent: Saturday, August 3, 2013 12:31 PM Subject: Re: [INUG-Users] nco_p_mttrapd not running Your probe props file are by default in $OMNIHOME/probes//*.props Example: $OMNIHOME/probes/linux2x86/mttrapd.props for linux %OMNIHOME%\probes\win32\ping.props for windows To see what is uncommented and the probe will try to use perform --> grep -v ^# $OMNIHOME/probes/linux2x86/mttrapd.props To start a probe they reference a file analogous to a /etc/hosts file This file is created via two command line steps: 1. Edit $NCHOME/etc/omni.dat 2. Run $NCHOME/bin/nco_igen <---This builds file $NCHOME/etc/interfaces.linux2x86 To see what properties your probe will try to run with when it starts --> $OMNIHOME/probes/nco_p_mttrapd -dumpprops Notice there is also a help with the probes which shows the command line options allowing you to over ride the pro