[Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp
SourceForge.net
noreply at sourceforge.net
Tue May 29 09:28:32 CEST 2007
Bugs item #1181554, was opened at 2005-04-12 17:27
Message generated for change (Comment added) 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: Open
Resolution: None
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 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