[Nagiosplug-devel] complication executing one plugin by another

Bob Ingraham bobi at netshel.net
Thu Sep 22 14:09:55 CEST 2005


Of course, it occurs to me that this solution works well for check_procs
under Solaris, but screws things up for other platforms (AIX, Linux, etc.)
that use their native ps programs.

I suppose that if you bracket the Solaris-specific code with:

#ifdef SOLARIS
    /* Build the path to our co-plugin */
    strcpy(PluginPath, argv[0]);
    if ((cp = strrchr(PluginPath, PATH_DELIMITER)) != NULL)
        strcpy(cp+1, PS_COMMAND);
    else  /* No path prefix found - assume that the system path works */
        strcpy(PluginPath, PS_COMMAND);

    /* Now use the spopen() command to exec our co-plugin */
    child_process = spopen (PluginPath);
#else
    child_process = spopen (PS_COMMAND);
#endif



Other than that, the cleanest solution (one that requires no modifications
to check_procs.c) appears to be:


Have configure create the "#define PS_COMMAND" string in config.h with the
path specified by --prefix.  For example:

#define PS_COMMAND "${prefix}/libexec/pst3"

Again, though, this requires Solaris-specific detection logic in configure.


This is the solution that I implemented in our environment.

Bob


> Sorry, here's a correction to the sample code snippet in my prior e-mail
> below.
>
> The call to spopen() should read:
>
>    /* Now use the spopen() command to exec our co-plugin */
>    child_process = spopen (PluginPath);
>                            ^^^^^^^^^^
>
> Bob
>
>> I have an idea...  :-)
>>
>> It seems to me that the plugins are always executed with full path
>> information contained in argv[0], since the nrpe.cfg file usually
>> contains
>> the full path information and this is what nrpe use to exec() these
>> plugins.
>>
>> Therefore, if you know that you want to execute a fellow plugin (why
>> does
>> that not sound right? ;-) ), then all you need do is extract the full
>> path
>> info from main's argv[0] vector, and use that to construct the path the
>> "peer" plugin.
>>
>> Something like:
>>
>> #define PS_COMMAND   "pst3"   /* From config.h */
>>
>> #ifdef WINDOZE
>> #define PATH_DELIMITER '\\'
>> #else
>> #define PATH_DELIMITER '/'
>> #endif
>>
>> int main (int argc, char **argv)
>> {
>>     char PluginPath[MAX_PATH+1], *cp;
>>
>>     /* ...  snip ... */
>>
>>     /* Build the path to our co-plugin */
>>     strcpy(PluginPath, argv[0]);
>>     if ((cp = strrchr(PluginPath, PATH_DELIMITER)) != NULL)
>>         strcpy(cp+1, PS_COMMAND);
>>     else  /* No path prefix found - assume that the system path works */
>>         strcpy(PluginPath, PS_COMMAND);
>>
>>     /* Now use the spopen() command to exec our co-plugin */
>>     child_process = spopen (PS_COMMAND);
>>
>>    /* ...  snip ... */
>> }
>>
>> Hope this is helpful...
>>
>> Bob
>>
>>> if you've read the subject, you may be thinking "why the hell would
>>> you want to do that?"
>>>
>>> one example is the latest modification i've made (or half-made,
>>> hence the email) to check_procs, to call the pst3 program submitted
>>> by bob ingraham, which will also reside in the plugin installation
>>> dir.
>>>
>>> the problem is that to execute pst3, one has to either supply the
>>> full path or assume that it is in the path.  the problem with the
>>> latter is that it probably will not be in the system path, and
>>> the problem with the former is that i can't figure out a good way
>>> to supply the path to the plugin.
>>>
>>> so, i see a couple iof options here:
>>>
>>> - modify configure.in, config.h and/or Makefile.am's to pass the
>>>   information at compile-time
>>> - modify check_procs to include the pst3 code natively, making this
>>>   a moot issue.
>>>
>>> comments?  in the meantime, i'll leave the CVS HEAD configure.in script
>>> with ac_cv_ps_command="pst3" (no path), so if someone cares they
>>> can copy the binary into their paths.  if i don't hear back, i think
>>> i'll try and work with option 2.
>>>
>>>
>>> 	sean
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by:
>> Tame your development challenges with Apache's Geronimo App Server.
>> Download it for free - -and be entered to win a 42" plasma tv or your
>> very
>> own Sony(tm)PSP.  Click here to play:
>> http://sourceforge.net/geronimo.php
>> _______________________________________________________
>> Nagios Plugin Development Mailing List
>> Nagiosplug-devel at lists.sourceforge.net
>> Unsubscribe at
>> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
>> ::: Please include plugins version (-v) and OS when reporting any issue.
>> ::: Messages without supporting info will risk being sent to /dev/null
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________________
> Nagios Plugin Development Mailing List
> Nagiosplug-devel at lists.sourceforge.net
> Unsubscribe at
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>





More information about the Devel mailing list