[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

4470.0. "event sink was started successfully but is not currently communicating error - mcc_tcpip_sink" by MDCRAB::STUART (Scott Stuart - MARVA Network Sales Support DTN 341-3132 - MARVA District) Fri Jan 29 1993 17:24

I can get in a situation where I have multiple (10+) 

/usr/mcc/mmexe/mcc_tcpip_sink processes running.  I then get an alarm
excpetion ' the event sink was started successfully but it not currently
communicting'

Normally I get one mcc_tcpip_sink process that seems to get started up when
I create my first SNMP Trap rule.

1) What is the proper way to start and stop the mcc_tcpip_sink process?

2) AM I doing something incorrectly to cause all these process to be created?

thanks ... scott
T.RTitleUserPersonal
Name
DateLines
4470.1MOLAR::YAHEY::BOSESun Jan 31 1993 15:4119
	The event sink is started automatically when a getevent call
	is made to the SNMP AM. In your case the call is made by the
	alarms module. The sink stops automatically when there are no
	more getevent calls outstanding, ie. when the alarm rules are
	disabled.

	You should not have to worry about starting or stopping the event
	sink, it is all done automatically. Normally, there should never
	be more than one event sink running. If you try starting multiple
	sinks by hand, only one should stay up. The sink tries to bind to 
	port 162 and if it fails to do so, it assumes that another sink
	has already bound to it and exits. This is why your observation
	of seeing multiple event sinks running seems strange.

	Can you do a ls -l /usr/mcc/mmexe/mcc_tcpip_sink and post the result
	here. I want to check if the executable has the correct permissions.

	Rahul.
4470.2Same problem with VMSRDGENG::PRATTMon Feb 01 1993 06:556
I have also seen this error with the VMS kit - it has only occured since 
upgrading from T1.3 to T1.3.1

See problem 2) in note 4447.0

Ian Pratt
4470.3QAR?RAMPAL::MINTZErik MintzMon Feb 01 1993 08:364
Is there a QAR for this problem?  V1.3 is getting close to code freeze
for SSB, so we need to make sure anything serious is addressed right away.

-- Erik
4470.4MOLAR::YAHEY::BOSEMon Feb 01 1993 09:1010
	Filed as QAR # 136 in MCC013_EXT database.

	RE .0 & .2

	Can you mail me the exact sequence of steps that lead to the
	sort of behaviour you noticed. I will try to reproduce the problem
	on my system.

	Rahul.
4470.5i'll try to duplicate itMDCRAB::STUARTScott Stuart - MARVA Network Sales Support DTN 341-3132 - MARVA DistrictMon Feb 01 1993 09:3017
re: .1 

# ls -l /usr/mcc/mmexe/mcc_tcpip_sink
-rwsr-xr-x  1 root      1032192 Nov  6 15:02 /usr/mcc/mmexe/mcc_tcpip_sink


re: .4

I will try to duplicate the problem, but it does not seem to be a simple matter.
I was disabling, deleting and recreating rules multiple times via the fcl.

I tried it a few times this morning and could not reprodce the problem.

I will post the results later, if I can reproduce the problem


thanks ... scott
4470.6MOLAR::YAHEY::BOSEMon Feb 01 1993 19:4814
	RE. 0

	The sort of behaviour you are seeing may happen when there is a
	corruption in the event pool. That probably explains why the
	problem is not reproducible.

	RE .2

	Your problem is due to a bug in the Alarms FM which prevented
	it from handling IP reachability up and down events properly. That 
	problem has already been fixed (and should be available in the SSB kit).

	Rahul.
4470.7VMS and MCC V1.3 still the sameANTIK::WESTERBERGStefan Westerberg DS StockholmMon Mar 15 1993 13:166
	Hi, I have installed V1.3 and I'am still seeing this problem.
	I thought this should had been fixed in V1.3.

	Could I have some other problem on my system ?

	/Stefan
4470.8what problem are you seeing?MOLAR::PERRYTue Mar 16 1993 10:3210
    Hi Stefan,
    
    Can you describe this problem you are seeing in the V1.3 kit? There
    were a couple of problems discussed in this note and so I am not quite
    sure which problem you're referring to. Thanks.
    
    Jim
    
    
    
4470.9Problem occures when starting iconic mapANTIK::WESTERBERGStefan Westerberg DS StockholmWed Mar 17 1993 11:1823
	Hi Jim,

	I get the error message:

	Notify Request 1 for domain allen encounterd an exception
	Unexpected condition returned to Notification FM.
	Exception Encountered
	The Event Sink is running, but not communicating; cannot restart sink.

	during startup of iconinc map. The notification service is automaticly
	started with a notify request startup file. The first line in that file
	is:

	Notify Domain allen Entity List = (snmp *), Events = (any events)

	The only problem I'am seeing is the error message returned from the
	notification FM. All other stuff seems to work, the tcpip sink process
	is running and I correctly receive traps from a Chipcom hub.

	/Stefan

	
	
4470.10Heellppp ,,...EVTAI1::RENOUVELMon Sep 27 1993 05:1310
    
    Hello,
    
    I have this type of problem too.
    Did somebody find a solution.
    I can not see any traps coming back to my DECmcc platform.
    
    help please.
    
    Patrick
4470.11MOLAR::YAHEY::BOSEMon Sep 27 1993 10:415
	Try shutting down MCC and starting again and see if the problem
	goes away. I will track down this problem when I find some time.

	Rahul.