Before process monitoring

If the Nagios plugin check_procs refuses to work

If you want to check whether a particular process is working, you usually use the check_procs plugin from the Nagios plugin package under Nagios/Icinga. No problem provided the underlying operating system is Linux. With Solaris it gets complicated.

For time and/or policy reasons, self-compiling is often not even considered on systems which only have to be monitored. In most cases, the gcc and co. tool first has to be installed. Binaries are therefore required. These can be self-compiled on an adequately equipped system or be obtained from the net. They can be found, for example, at Nagios Exchange.

There is rarely write access to the complete file system on customer servers and it usually does not matter where Nagios plugins are specifically located in the file tree: The path given by configure is irrelevant to check_disk, check_swap and co. But this is not the case with check_procs: taking a “cherry-picking” approach and copying the plugin singularly to the file tree of the host to be monitored will often prove unsuccessful. (The Nagios plugin team is nevertheless self-critical enough to add a note about this scenario in the configure.in file from the 1.4.14 Nagios plugin source code which says

"this is a very, very ugly hack, to hardcode the location for plugins.")

For demonstration purposes, let’s take the example of Guntram Blohm on the Nagios exchange or at his homopage http://www.guntram.de/nagios/ provided 1.4.14er binaries for Solaris Intel:

> scp check_procs <zielhost>:/usr/local/nagios/bin/plugins/third_par
ty/
> ssh  root@<zielhost> '/usr/local/nagios/bin/plugins/third_party/ch
eck_procs -C java -s RSI -c 1:1'
Unable to read output

A check_procs -h indicates that the plugin is run-capable in principle, but what does this cryptic error message mean? A quick bit of research online shows that lots of people are clearly asking themselves the same question, yet no answer is forthcoming on lots of forums and newsgroups.

check_procs, although written in C, does not implement the process request itself but instead uses external tools like ps. The error message “Unable to read output” refers to the output of this external tool.

Which tool is used and how its output is to be interpreted is determined at the time of compiling with the configure options --with-ps-command=<PFAD>, --with-ps-format=<FORMAT>, --with-ps-cols=<ANZAHL> und --with-ps-varlist=<LISTE>. As configure --help unfortunately does not provide examples, you are well advised not to rely on a trial and error approach, but instead to look at the defaults in configure.in (the defaults for most Linux systems are found here):

ac_cv_ps_varlist="[procstat,&procuid,&procpid,&procppid,&procvsz,&pr
ocrss,&procpcpu,procprog,&pos]"
ac_cv_ps_command="$PATH_TO_PS axwo 'stat uid pid ppid vsz rss pcpu 
comm args'"
ac_cv_ps_format="%s %d %d %d %d %d %f %s %n"
ac_cv_ps_cols=9

In this case, check_procs evaluates the output of

/bin/ps axwo 'stat uid pid ppid vsz rss pcpu comm args'

based on the default of the other ac_cv_ps_* variables.

But what if you have cleaned up after compilation or only have binaries available in any case? check_procs is kind enough to reveal the command used if the plugin is called up with the option -vv You only have to take a quick look at the first lines entered with the prefix CMD. With Guntram Blohm’s check_procs this is:

> ssh root@<zielhost> '/usr/local/nagios/bin/plugins/third_party/che
ck_procs -vv|head -1'
CMD: /usr/local/nagios/libexec/pst3

pst3 is another individual development from the Nagios plugin team, which Guntram Blohm also includes in SunOS_i386-5.10-plugins-1.4.14-binaries.tar.gz . If you copy the program to the path indicated....

> scp -r usr/local/nagios/libexec/pst3 root@<zielhost>:/usr/local/na
gios/libexec/

check_procs also works perfectly. Problems only arise when it is used as a non-root, for example, if the customer is not happy using /usr/local/nagios/libexec/.

New Comment: