[Nagiosplug-help] Helprequest about Plugin Return Codes

[Andreas Ericsson]

Hendrik Baecker wrote:
> Hi Andreas,
> 
> sorry to disturb yourself directly. But I think it is quiet not good to
> post my trash to the list.
> 

Please don't. I don't run a free programmers education by email, and I 
have neither time nor inclination to offer free support.

> My problem is of following nature: We have two nagios boxes, one as
> master one as slave (notifications and checks disabled). I want to check
> the alive status of the master from the slave with a better tool than
> our quick and dirty shell script which only pings the master, writes
> error files, checks them and than set an external command to enable
> checks and noti's on the backup.
> 
> 7 Years ago I loved programming in C in School. Now I want to get back
> to my secrect favorite and write some little tools in C for our Nagios.
> Therefor I thought I can begin with writing some code to execute the
> check_nrpe hiring to our master server get the alive status and decide
> to enable the backup system or not.
> 
> My little program just, as you assumed, popen()s the check_nrpe prints
> out the plugin output and after this I get an Integer out of:
> 

Why not let Nagios run check_nrpe by itself? It's what it does, you 
know, and it does it properly as well.

>     exitcode = pclose(nrpepipe);
> 
> and this var exitcode is the unshifted unmasked exitcode you mentionend.
> 

exitcode = pclose(nrpepipe);

if(WIFEXITED(exitcode))
	exitcode = WEXITSTATUS(exitcode);
else { /* handle the system error */ }

> As far as my "C buggy Brain" remembers it couldn't be possible to see
> the unmasked unshifted exitcode, or am I missing something?
> 

You're obviously missing something. Incidentally, you're missing exactly 
what I told you before, which is just a tad annoying; You need to use 
the WEXITSTATUS() macro when using popen() from C. If you still don't 
understand why then I suggest you get some good books on novice C 
programming, read /usr/include/bits/waitstatus.h and grok the man-pages 
and kernel-sources concerning the execve(2) system call. The 
kernel-sources from any OS and/or version should do, since its behaviour 
has more or less been written in stone since 1983.

> Btw: I am not working with any kind of the headers out from the plugins.
> 

That doesn't matter in the slightest. You'll need to include 
<sys/wait.h> though, or the macro won't be defined (<sys/wait.h> 
includes <bits/waitstatus.h> and re-names and properly casts the end 
user macros).

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer