check_tcp behavior

[Skip Montanaro]

    Dylan> I'm using the check_tcp plugin to check various ports that are
    Dylan> open on many of our boxes opened by homegrown applications. The
    Dylan> developers are concerned that the plugin might produce an output
    Dylan> on the remote machine that would cause issues with the
    Dylan> application.

    Bill> This actually was a very good question and raised a concern with
    Bill> me so I looked at my Solaris servers to see if it was recording
    Bill> anything...I have it checking ports for a homegrown script that
    Bill> starts multiple instances of the Tangram Asset tracking software
    Bill> on about 50+ ports and load balanced across several servers and in
    Bill> all the accounting logs for Tangram that I checked I see no record
    Bill> of the plugin attempts but packet captures are showing the plugin
    Bill> doing it's thing

A previous homegrown system monitor here used to perform a simple
connect/disconnect test for the Syncsort Backup Express listener on the
machines to be backed up.  Apparently (this predates my time here), that
hosed up the listener, so they wound up disabling that test.

I haven't encountered any other applications which work that way (and we've
dumped Backup Express in the meantime), but it's not altogether out of the
realm of possibility tha simply connecting and disconnecting won't hose the
server listening at the other end.

-- 
Skip Montanaro
Got gigs? http://www.musi-cal.com/submit.html
Got spam? http://spambayes.sf.net/
skip at pobox.com


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null