[Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp

SourceForge.net noreply at sourceforge.net
Thu May 31 18:48:52 CEST 2007


Bugs item #1181554, was opened at 2005-04-12 17:27
Message generated for change (Settings changed) made by psychotrahe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Simon Bellwood (sb-netman)
Assigned to: Matthias Eble (psychotrahe)
Summary: 1.4-3: Bug in check_tcp

Initial Comment:
I'm using check_imap with perfparse, and it's returning
critical for all values.

It seems the problem is that when no critical or
warning value is passed to it on the command line, it
defaults to use 0.000 and 0.000 respectively. Perfparse
then sees that the check time (say 0.002 seconds) is
above 0 and flags a CRITICAL warning.

I've had a look at the code, and the return happens at
check_tcp.c:389, where fperfdata is called.
fperfdata is provided by utils.h which sets both types
to a double, so I suspect it's not as simple as
changing check_tcp.c to return nulls if the -w and -c
flags aren't given :/

----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-05-29 21:31

Message:
Logged In: YES 
user_id=1694341
Originator: NO

I fixed this in cvs, now. 

You can try the latest snapshot.

Matthias

----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-05-29 09:28

Message:
Logged In: YES 
user_id=1694341
Originator: NO

after looking at the developer guidelines, it seems that the 0 is wrong
indeed:

6. warn, crit, min or max may be null (for example, if the threshold is
not defined or min and max do not apply). Trailing unfilled semicolons can
be dropped

imo FLAG_TIME_WARN and FLAG_TIME_CRIT need to be recognized when fperfdata
is called.

Will look at this in the next days..



----------------------------------------------------------------------

Comment By: Simon Bellwood (sb-netman)
Date: 2007-05-29 08:44

Message:
Logged In: YES 
user_id=1156501
Originator: YES

The problem is that check_tcp returns "0" and "0" for its warning and
critical values, even though they are undefined.

----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-05-27 11:54

Message:
Logged In: YES 
user_id=1694341
Originator: NO

Hi Simon,

I can only hardly understand your bugreport, too.
Why don't you just set a warning and critical threshold? 
To me they are mandatory if you want to graph the response time.

I'm about to set this report to pending since there has been an open
question
for a long time. This report will get deleted if the submitter will not
reply in the next 14 days.

Matthias

----------------------------------------------------------------------

Comment By: M. Sean Finney (seanius)
Date: 2005-09-19 16:58

Message:
Logged In: YES 
user_id=226838

hi, are you still interested in resolving this bug?  if so,
i still need to know what the perfparse system will need to
represent and "undefined" number, or whether no perfparse
data should be
output at all in such a case.

----------------------------------------------------------------------

Comment By: M. Sean Finney (seanius)
Date: 2005-05-02 15:07

Message:
Logged In: YES 
user_id=226838

sorry, i should be a little more clear on this:

is perfparse capable of parsing an "unknown" or "undefined"
value?  if so, how should it look?  otherwise, would it make
sense to just not pass the information to perfparse at all?
 if so how should that look?

you're right that there's no way to pass such values in the
current code, but it wouldn't be too hard to add this
functionality, as long as i knew what i was doing :)

----------------------------------------------------------------------

Comment By: Simon Bellwood (sb-netman)
Date: 2005-05-02 09:14

Message:
Logged In: YES 
user_id=1156501

> i don't believe arbitrarily setting the warn/critical
> values is the appropriate response.

But this is what utils.h does (used by check_tcp.c), not
perfparse.
There seems to be no way of returning an unknown value, so
it uses 0.000 instead.
perfparse sees the "unknown" warning and critical values as
0.000, so uses them.

----------------------------------------------------------------------

Comment By: M. Sean Finney (seanius)
Date: 2005-05-01 22:26

Message:
Logged In: YES 
user_id=226838

hi,

i'm still not sure what the solution to this should be.  i
don't believe arbitrarily setting the warn/critical values
is the appropriate response.  is there an undef value in
perfparse?

----------------------------------------------------------------------

Comment By: Simon Bellwood (sb-netman)
Date: 2005-04-19 08:52

Message:
Logged In: YES 
user_id=1156501

But the plugin returns "0" and "0" for its warning and
critical values, even though they are undefined - isn't that
a bug?

----------------------------------------------------------------------

Comment By: M. Sean Finney (seanius)
Date: 2005-04-19 01:50

Message:
Logged In: YES 
user_id=226838

perhaps there's an "undef" value that could be used in such
a case?  i really don't know much about the whole perfparse
thing since i use a seperate system from nagios for
monitoring performance data.

otherwise, i think the system is doing exactly what it's
supposed to be doing, and would need some convincing why the
answer isn't to just pass the warning and critical arguments
to check_tcp.

----------------------------------------------------------------------

Comment By: Simon Bellwood (sb-netman)
Date: 2005-04-18 09:01

Message:
Logged In: YES 
user_id=1156501

I was hoping that one of the developers would either say:
i) Oh no wait, there's an easy fix for this
ii) Tell perfparse to treat 0.0 as "no value"

Although ii) might be wrong in some cases, i.e. when 0 was
considered a good value (perhaps for items where a measure
from the normal was taken - can' think of any examples atm)

----------------------------------------------------------------------

Comment By: M. Sean Finney (seanius)
Date: 2005-04-18 00:14

Message:
Logged In: YES 
user_id=226838

hi,

what exactly are you suggesting as a fix?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880




More information about the Devel mailing list