[Nagiosplug-devel] [ nagiosplug-Bugs-706851 ] check_tcp misses expect string without newline

[SourceForge.net]

Bugs item #706851, was opened at 2003-03-20 07:15
Message generated for change (Settings changed) made by kdebisschop
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=706851&group_id=29880

Category: None
Group: Release (specify)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ade Rixon (aderixon)
Assigned to: Karl DeBisschop (kdebisschop)
Summary: check_tcp misses expect string without newline

Initial Comment:
In check_tcp.c 1.13, the following lines were added
(line 261):
if (buffer[i-2] == '\r' && buffer[i-1] == '\n')
                                break;

I have a TCP service that returns a string on
connection without a trailing newline. It used to be
detected by the -e option to check_tcp. The above code
breaks this behaviour and causes check_tcp to wait
until the timeout is reached, whereupon it fails.

Can this either be configurable, or be removed?

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

Comment By: Ade Rixon (aderixon)
Date: 2003-06-03 07:27

Message:
Logged In: YES 
user_id=145082

Today's snapshot works fine:
$ ./check_tcp -H his06 -p 4097 -e K -m 1 -v
K
0 1
TCP OK -   0.019 second response time on port 4097 [K]|time=
 0.019

Thanks for sorting this one out, I will update when there is
a new stable release.

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

Comment By: Karl DeBisschop (kdebisschop)
Date: 2003-06-02 10:41

Message:
Logged In: YES 
user_id=1671

yes - I believe it should have been '>='

I will make the change now, it should be in the next snapshot

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

Comment By: Ade Rixon (aderixon)
Date: 2003-06-02 07:43

Message:
Logged In: YES 
user_id=145082

Nope, same behaviour with the new version:

$ pwd
/opt/home/me/src/C/nagios-plugins-200306020007/plugins
$ ./check_tcp -H his06 -p 4097 -e K -m 1 -v
CRITICAL - Socket timeout after 10 seconds
>From truss:
connect(4, 0x00028480, 16, 1)                   = 0
read(4, " K", 1023)                             = 1
read(4, 0x000288E8, 1023)       (sleeping...)
    Received signal #14, SIGALRM, in read() [caught]
read(4, 0x000288E8, 1023)                       Err#4 EINTR

Perhaps because the terminating conditional is:
strlen(status)>maxbytes
and in this case status never goes above maxbytes (1)?

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

Comment By: Karl DeBisschop (kdebisschop)
Date: 2003-06-02 06:40

Message:
Logged In: YES 
user_id=1671

I applied the proposed change the other day. I beleive it
should work for you - if you limit to 1 byte, it will make
only 1 recv() call.

Can you try a build from CVS or one of the daily snapshots
at http://nagiosplug.sourceforge.net/snapshot/  and let us
know how it goes for you? I hpe to close the issue out and
make a bug fix release soon.

(the option is -m or --maxbytes)

Thanks.

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

Comment By: Ade Rixon (aderixon)
Date: 2003-06-02 03:52

Message:
Logged In: YES 
user_id=145082

To clarify:
On connect to the port, the server immediately returns
either 'K' or 'N' (no trailing newline), which indicates
whether it is accepting requests or not.

If your proposed cap on bytes fetched means that I could
specify "fetch exactly one byte" and this would work then
yes, that is an acceptable solution.

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

Comment By: Karl DeBisschop (kdebisschop)
Date: 2003-06-01 00:27

Message:
Logged In: YES 
user_id=1671

The issue is not that the lines were added, it's that the
old version could fail if he first line of text was more
than MAXBUF char long. 

1.12 calls recv once, 1.13 calls recv until the app stops
sending. Are you trying to monitor a streaming app by chance?

I propose that the solution is to add an option for a cap on
the number of bytes that check_tcp should fetch. Will that
work for you?


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

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