TCP Listener Failed to Start Service will stop. active checks will be disabled. :Only one usage of each socket address (protocol/network address/port) is normally permitted
As I was readding the events, I was thinking I have not seen this sequence of event ID since version 2 then Examined the END event and saw that it was from version 2.x
To start with please upgrade to a newerver version of NC_NEt IF you can, there are several bug fixes as well as stability and security enancements included in the new version as well as new commands and newer optimized version of performance counters (with a configurable testinteval) and better eventlog and WMI queries.
Naturally the current version is only posted here on SourceForge.
The errors do not directly point to Perfornace counters causing the issue.
I would need more information.
IF NC_NEt wsa never run on that machine before:
check performance counters for CPU instances if this option is not avalible
then there is a startup.cfg option for setting cpu single which should clear it up.
Equally the above message sequence could indicate that NC_Net was stoped and some other application started and is currently using that Network port.
check what applications are using the ports (netstat or TCPView) If it is still NC_NEt then I would advise:
1) backup NC_NEt folders to a different location or disk
2) uninstall nc_net
3) delete all the Nc_net files
4) Install the newest version of NC_NEt
5) configure the new version since some syntex and config files have changed
6) compile check_nc_net.c as check_nt to take advantage of the added functionality and built in Help --help=CMDNAME
Hope this helps
please respond back with feedback
Tony
Donations for NC_NEt are accepted via MontiTech.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi thanks for the response I have reinstalled NC_NET
Recompiled check_nc_net.c
Haven't had any more of those specific issues lately will keep monitoring.
I use nagios 2.7 and have added service dependency checks on a straight uptime check on NC_NET.
So when NC_NET goes critical I don't get a thousand alerts.
I also changed the check_nc_net.c to make
No data was received from host!
Connection refused by host
Connection refused
Instead of going critical or warning to go Unknown.
Question is I see there is a variable to do this without hacking the code as I did, where can I set that?
Was wondering alot of these alerts seem to be from query timeouts.
For example how are the queries for disk space carried out. WMI query or Perfcounter query?
Thanks for the great agent
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as for the query timeouts,
Typically checking WMI takes longer than other tests,
Diskspace is tested via WMI since Freespace is Reported in WMI but would only be infered if using Performance Counters.
I know this is a minor difference since the end result is the same but WMI allows for any disk type reported to the Logical disk node.
The biggest culprit of chewing up time is the event log checks.
convert to EventLogNew since the old event log only really supports one check before backing up the check timeout to unresonable levels when the system has Large event logs, (More than several megs)
the Event log new runs checks in an optimal way such that they will return quickly when testing only the last 10 min of the event log.
Another way to speed up checktime is to use Passive checks (if this is availible) Active checks process after the command is recieved. this keeps the socket opened and increases time before the next command can be recieved. typically when checks are preformed every 5-10 min, there is plenty of time for the checks to process before the timeout (assuming the Timeout is set to 20s or so)
Passive checks in NC_NEt all process before the communications is open thus there is never an issue of timeout unless there is a network issue inducing the connectivity issue. Check_nc_net would allow for configuration of passive checks, but the startup congfig and the NSCA server would still need to be configured manually,
For diagnosing the Timeout, run check_nt/check_nc_net from the command line, testing each command and see what command does not return right away. the commands that take the longest should be substituted with quicker commands (like passive check versions) or alternative mechanisms to fetch the data. for instance I found on WMI queries to Disks, with a good where statment that avoids slow disks (like floppies) would cause the query to return quicker. since the Disk WMI actually polls each disk within the WMI subsystem before returning the results to the nc_net
Hope this helps,
tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there would this also be from corrupted performance counters?
###################
Event Type: Warning
Event Source: NC_Net
Event Category: None
Event ID: 3006
Date: 2008/10/13
Time: 05:19:29 PM
User: N/A
Computer: ********
Description:
Exeption Stopping passive check thread : Object reference not set to an instance of an object.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Event Type: Information
Event Source: NC_Net
Event Category: None
Event ID: 3005
Date: 2008/10/13
Time: 05:19:29 PM
User: N/A
Computer: *******
Description:
NC_Net Service Ending :-NC_Net 2.28 07/16/05
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Event Type: Warning
Event Source: NC_Net
Event Category: None
Event ID: 1005
Date: 2008/10/13
Time: 05:19:33 PM
User: N/A
Computer: *****
Description:
TCP Listener Failed to Start Service will stop. active checks will be disabled. :Only one usage of each socket address (protocol/network address/port) is normally permitted
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
As I was readding the events, I was thinking I have not seen this sequence of event ID since version 2 then Examined the END event and saw that it was from version 2.x
To start with please upgrade to a newerver version of NC_NEt IF you can, there are several bug fixes as well as stability and security enancements included in the new version as well as new commands and newer optimized version of performance counters (with a configurable testinteval) and better eventlog and WMI queries.
Naturally the current version is only posted here on SourceForge.
The errors do not directly point to Perfornace counters causing the issue.
I would need more information.
IF NC_NEt wsa never run on that machine before:
check performance counters for CPU instances if this option is not avalible
then there is a startup.cfg option for setting cpu single which should clear it up.
Equally the above message sequence could indicate that NC_Net was stoped and some other application started and is currently using that Network port.
check what applications are using the ports (netstat or TCPView) If it is still NC_NEt then I would advise:
1) backup NC_NEt folders to a different location or disk
2) uninstall nc_net
3) delete all the Nc_net files
4) Install the newest version of NC_NEt
5) configure the new version since some syntex and config files have changed
6) compile check_nc_net.c as check_nt to take advantage of the added functionality and built in Help --help=CMDNAME
Hope this helps
please respond back with feedback
Tony
Donations for NC_NEt are accepted via MontiTech.com
Hi thanks for the response I have reinstalled NC_NET
Recompiled check_nc_net.c
Haven't had any more of those specific issues lately will keep monitoring.
I use nagios 2.7 and have added service dependency checks on a straight uptime check on NC_NET.
So when NC_NET goes critical I don't get a thousand alerts.
I also changed the check_nc_net.c to make
No data was received from host!
Connection refused by host
Connection refused
Instead of going critical or warning to go Unknown.
Question is I see there is a variable to do this without hacking the code as I did, where can I set that?
Was wondering alot of these alerts seem to be from query timeouts.
For example how are the queries for disk space carried out. WMI query or Perfcounter query?
Thanks for the great agent
as for the query timeouts,
Typically checking WMI takes longer than other tests,
Diskspace is tested via WMI since Freespace is Reported in WMI but would only be infered if using Performance Counters.
I know this is a minor difference since the end result is the same but WMI allows for any disk type reported to the Logical disk node.
The biggest culprit of chewing up time is the event log checks.
convert to EventLogNew since the old event log only really supports one check before backing up the check timeout to unresonable levels when the system has Large event logs, (More than several megs)
the Event log new runs checks in an optimal way such that they will return quickly when testing only the last 10 min of the event log.
Another way to speed up checktime is to use Passive checks (if this is availible) Active checks process after the command is recieved. this keeps the socket opened and increases time before the next command can be recieved. typically when checks are preformed every 5-10 min, there is plenty of time for the checks to process before the timeout (assuming the Timeout is set to 20s or so)
Passive checks in NC_NEt all process before the communications is open thus there is never an issue of timeout unless there is a network issue inducing the connectivity issue. Check_nc_net would allow for configuration of passive checks, but the startup congfig and the NSCA server would still need to be configured manually,
For diagnosing the Timeout, run check_nt/check_nc_net from the command line, testing each command and see what command does not return right away. the commands that take the longest should be substituted with quicker commands (like passive check versions) or alternative mechanisms to fetch the data. for instance I found on WMI queries to Disks, with a good where statment that avoids slow disks (like floppies) would cause the query to return quicker. since the Disk WMI actually polls each disk within the WMI subsystem before returning the results to the nc_net
Hope this helps,
tony