[Nagiosplug-devel] r1879: check_tcp now returns UNKNOWN with an invalid hostname on command line

Thomas Guyot-Sionnest dermoth at aei.ca
Tue Jan 8 13:27:20 CET 2008

Hash: SHA1

On 08/01/08 06:48 AM, Ton Voon wrote:
> On 8 Jan 2008, at 11:27, Thomas Guyot-Sionnest wrote:
>> Hash: SHA1
>> In check_tcp.c svn logs:
>> -  
>> ------------------------------------------------------------------------
>> r1879 | tonvoon | 2007-12-19 05:08:06 -0500 (Wed, 19 Dec 2007) | 2  
>> lines
>> check_tcp now returns UNKNOWN with an invalid hostname on command line
>> This breaks some tests (at least check_ftp and maybe others)... I  
>> fixed
>> check_ftp but I can't guarantee I'll fix all breakages if there's  
>> more.
>> Also while I see the point of using UNKNOWNs for unknown hosts, I'm
>> thinking whoever is testing a remote host he doesn't control with
>> check_tcp will receive UNKNOWN instead of CRITICAL if the hostname
>> changes which might not be the expected behavior.
>> So it should be well documented that whoever is running checks with
>> hostnames should check with check_dns as well, especially for hosts  
>> they
>> don't have control over.
> Fair point. I specifically made this change because in a Nagios  
> configuration $HOSTADDRESS$ wasn't set, so the check_tcp was  
> effectively running:
> check_tcp -H -w 5
> and mistaking -w for the hostname. My thinking was that this was a  
> command line options error, hence UNKNOWN. However, I've obviously  
> implemented it as a hostname resolution check.
> Looking at http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN78 
> , it's a higher level error so shouldn't be UNKNOWN and should be  
> So, sorry, I screwed up here twice: once for changing to UNKNOWN, and  
> twice for not checking the test results to see the impact.
> I'll revert back now.

The arguments goes in both ways. It is fair to think name resolution
belongs to check_dns, and in my setups I use IPs everywhere I can and
the dns servers have their own checks. I didn't push my vote towards the
reversal of your commit because some other plugins I checked goes
UNKNOWN on invalid hosts too.

The developer guideline should be clear on this (if it's not already)
and plugins not following the specs should be fixed.

I don't believe this should apply for plugin that use a protocol to
check something behind it (i.e. check_snmp, check_nrpe, check_by_ssh,
check_nt). It that case this should be UNKNOWN with optionally the
possibility to return CRITICAL on protocol unreachable. So instead of
setting 10 thousand dependencies in Nagios you can just have one check
for the protocol (using the CRITICAL option or negate) and all other
returning UNKNOWN when unreachable - this ways you won't get a "pager
bomb" then the service does down ;)

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Devel mailing list