CHECK_NRPE: Error - Could not complete SSL handshake

[and1100]

Hi,

It appears that I am receiving multiple false (CRITICAL) positives on a few particular servers:

CHECK_NRPE: Error - Could not complete SSL handshake.

The warnings recover almost instantly. Can someone explain the flow of events that may possibly be causing this and how I can resolve? It is generating a lot of unwanted and false email spam.

Thank you very much.

[tmcdonald]

What are your max_check_attempts and retry_interval set to for those services?

[and1100]

Ah:

Code: Select all

        max_check_attempts           1
        check_interval                     1
        retry_check_interval            1

Too small of a window?

[eloyd]

EDIT: I interpreted this as the hosts were not working, not that the services were going bad instantly and coming back. What follows is how to fix NRPE if it's not workign at all.

This may mean a bad xinetd nrpe file on the remote host(s). Edit /etc/xinetd.d/nrpe and look at the "only_from" line. Make sure your Nagios server IP address is listed there.

Example:

Code: Select all

# cat /etc/xinetd.d/nrpe
service nrpe
{
        flags           = REUSE
        socket_type     = stream
        port            = 5666
        wait            = no
        user            = nagios
        group           = nagios
        server          = /usr/local/nagios/bin/nrpe
        server_args     = -c /usr/local/nagios/etc/nrpe.cfg --inetd
        log_on_failure  += USERID
        disable         = no
        only_from       = 1.2.3.4
}

(I've changed our real Nagios IP Address to be 1.2.3.4). Make sure you restart xinetd on that machine: "service xinetd restart"

[and1100]

Hi Eric,

The checks actually work fine and report as OK most of the time. However, they sometimes intermittently fail with SSL handshake checks and generate false emails. I am considering upping my intervals and check attempts from the current value of 1.

Thanks.

[tmcdonald]

The config options I asked about are there to help smooth out the false positives. Even setting the max_check_attempts to 2 will help.

[eloyd]

Ah:

Code: Select all

        max_check_attempts           1
        check_interval                     1
        retry_check_interval            1

Too small of a window?

Hard to say without knowing what the checks are, but check_interval of 1 and retry_check_interval of 1 means every minute. So your configuration is checking every minute, and if it fails, it instantly becomes a HARD CRITICAL, and then it checks every minute to see if it comes back. Depending on your notification options, you may get a LOT of repeat negatives.

A better (or at least, more typical) approach might be a max_check_attempts=3, check_interval=5, and retry_check_interval=1. This would check every five minutes. If it goes bad, it's in a SOFT state, and it switches to checking every minute. After three bad states in a row (so a total of seven minutes being bad) it goes into HARD CRITICAL and starts notifying. It also flips back to checking every five minutes at that point.

May take some stress off your notification recipients.

[and1100]

Hi All,

It looks like adjusting the checks has created the desired outcome. Thank you very much for your help.