check_dhcp failing after 2.1 upgrade

[XenoPhage]

Hi there,

Looks like the check_dhcp plugin is having a problem since upgrading to 2014R2.1 .. Specifically, Nagios shows this error :

Code: Select all

(No output on stdout) stderr:

Running via CLI (with a sudo -u apache) shows the correct output :

Code: Select all

$ sudo -u apache /usr/local/nagios/libexec/check_dhcp -u -s 192.168.1.1 -r 192.168.100.100 -m C0:FF:EE:15:C0:01 -t 5
OK: Received 1 DHCPOFFER(s), 1 of 1 requested servers responded, requested address (192.168.100.100) was offered, max lease time = 86400 sec.

IPs and MAC Addresses have been modified to protect the guilty.

I'm not sure what the issue is here. That's the exact CLI command that Nagios is allegedly using. Testing the the test button in the config screen shows an immediate return of no output.

Thoughts?

[tmcdonald]

What are the permissions on the check_dhcp plugin?

[lmiltchev]

Testing from within CCM is not a 100% accurate. Does the actual check work in the GUI?

Service Detail-><your check>->Schedule a forced immediate check

Can you show us the service definition? Hide sensitive info.

[XenoPhage]

What are the permissions on the check_dhcp plugin?

-r-sr-xr-x 1 root root 175354 Dec 22 16:10 /usr/local/nagios/libexec/check_dhcp

Same as they've been for years.

[XenoPhage]

Testing from within CCM is not a 100% accurate. Does the actual check work in the GUI?

Nope, that's where I get the error :

(No output on stdout) stderr:

Can you show us the service definition? Hide sensitive info.

Sure :

Here's the command definition :

Code: Select all

define command {
       command_name                             check_dhcp
       command_line                             $USER1$/check_dhcp -u -s $HOSTADDRESS$ -r $ARG1$ -m $ARG2$ -t 5
}

And here's the service check :

Code: Select all

define service {
        service_description             DHCP Service Check
        use                             service-server-standard
        hostgroup_name                  dhcp-server-standard
        servicegroups                   dhcp-server-standard
        check_command                   check_dhcp!192.168.1.1!c0:ff:ee:15:c0:01!!!!!!
        register                        1
        }       

None of this has changed, only the upgrade from 2014R1.5 to 2014R2.1.

[lmiltchev]

It's a possible bug. We are digging into this as we speak. It seems like we are able to recreate the issue, when we pass the "-m" flag. Can you try removing the "-m" flag and see if it is going to work this way?

One more thing - I noticed that you used the IP address of the DHCP server (192.168.1.1) instead of the "requested IP"...

define command {
command_name check_dhcp
command_line $USER1$/check_dhcp -u -s $HOSTADDRESS$ -r $ARG1$ -m $ARG2$ -t 5
}
define service {
service_description DHCP Service Check
use service-server-standard
hostgroup_name dhcp-server-standard
servicegroups dhcp-server-standard
check_command check_dhcp!192.168.1.1!c0:ff:ee:15:c0:01!!!!!!
register 1
}

[XenoPhage]

It's a possible bug. We are digging into this as we speak. It seems like we are able to recreate the issue, when we pass the "-m" flag. Can you try removing the "-m" flag and see if it is going to work this way?

And that triggered my "let's play the escaping/quoting game" routine.. And that was it. If you put the mac address in quotes, it works. So it sounds like there's an escaping issue of some sort in play here.

So, I've worked around it, and the workaround is fine if that's the way things should be.. If not, then yes, I think there's a bug. At the very least, this might be considered a regression if the previous behavior was, in fact, valid.

Thanks!

[XenoPhage]

And that triggered my "let's play the escaping/quoting game" routine.. And that was it. If you put the mac address in quotes, it works. So it sounds like there's an escaping issue of some sort in play here.

So, I've worked around it, and the workaround is fine if that's the way things should be.. If not, then yes, I think there's a bug. At the very least, this might be considered a regression if the previous behavior was, in fact, valid.

Crap, spoke too soon. It fixes it for the test button in the GUI, but the actual check still seems to fail. No idea why, though.

[cmerchant]

Have you done an apply configuration after making the change in the service check?

[XenoPhage]

Have you done an apply configuration after making the change in the service check?

Yup. Just did it again, just to be sure. Same result, works via the test command (using either the IP or the DNS name, btw) but doesn't work via the normal check process.