check_http throwing 141 exit on ssl error

[Mike Lindsey]

On 9/14/12 11:25 AM, Justin T Pryzby wrote:
> This may be unrelated to the question of why it's exiting with a
> nonstandard, out of range exit status, but is port 83 really HTTP over
> SSL?  It seems as if the plugin sent an ssl initiation, and the remote
> side closed the connection (perhaps because it wasn't ssl?).
>
> Later, the plugin tried to gracefully end the ssl session, but the
> socket was already closed (ECONNRESET), resulting in EPIPE, which I
> think is expected.
When the remote device isn't in this current state that's causing it to 
close inbound connections immediately after the socket is opened, yes, 
that's an https port.

On 9/14/12 11:54 AM, Andreas Ericsson wrote:
> On 09/14/2012 08:09 PM, Mike Lindsey wrote:
>> I'm typically used to seeing this kind of error code for a missing
>> plugin, but I've got a device that is accepting tcp connections and then
>> due to a local misconfiguration, immediately closing them.
>>
>> But rather than a normal critical I'm getting:
>> """
>> (Return code of 141 is out of bounds)
>> """
>>
> SIGPIPE has sig id 13. When a program catches a signal, it returns
> the sigid as a negative number, but the field for the exit status
> is unsigned, so it gets translated to 128 + sigid instead.
>
> As I read it back, I realize that doesn't exactly make supersense
> to anyone not familiar with integer math as computers do it, but
> I can assure you that's the reason.
Yup, makes sense now, and if I'd bothered to hit the man page, I'd have 
groked that.  As it was I just assumed 141 was SIGPIPE, so almost there 
but with an invalid (and irrelevant assumption).

>> When run by hand I have:
>> """
>> root at ops-mon-nagios3 /usr/local/nagios/libexec $ ./check_http -H
>> device.domain.com -w "10" -c "20" -S -p "83" -f follow
>> CRITICAL - Cannot make SSL connection
>> root at ops-mon-nagios3 /usr/local/nagios/libexec $ echo $?
>> 141
>> """
>>
>> write(1, "CRITICAL - Cannot make SSL conne"..., 39) = 39
>> write(3, "\200w\1\3\1\0N\0\0\0
>> \0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0\300"..., 121) = -1 EPIPE
>> (Broken pipe)
>> --- SIGPIPE (Broken pipe) @ 0 (0) ---
>> +++ killed by SIGPIPE +++
>>
> And there's the SIGPIPE. Case closed.
>

Would it be appropriate for the check (and potentially any other 
nagios-plugins check that opens a socket) to trap SIGPIPE and return a 
normal valid critical?

As is, any http or https (or smtp or ldap, etc) check that's hitting a 
device behaving in this manner, is going to display a non-useful message 
in the Nagios UI, instead of the actual critical output. This is an 
error condition on a remote host, covered by what is normally valid 
working monitoring.  If this should be more cleanly caught by lower 
level parent dependency monitoring, how?  check_tcp returns 'ok' because 
the port opens.

If this is expected and desired behavior, should the output be updated 
to not include the misleading 'CRITICAL' prefix?

-- 
Mike Lindsey


------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
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