NAGIOS_* Env variables are not populated for process_perfdata.pl Nagios Core 4.4.9

[filosof86]

Hi,

Similar to #124

After updating from Nagios Core 3.0.6 to 4.4.9 I encountered the unavailability of the RRD graphs.

Looking deeper, it turned out that process-service-perfdata command had failed:

2023-03-28 08:07:06 [31241] process_perfdata.pl-0.4.10 starting in DEFAULT Mode
2023-03-28 08:07:06 [31241] Cant find Nagios Envirionment. Exiting ....

The command:

define command {
         command_name               process-service-perfdata
         command_line                  $USER2$/process_perfdata.pl
         }

In turn, it happens because the processperfdata.pl cannot find the NAGIOS* env vars

if ( !$ENV{NAGIOS_HOSTNAME} ) {
        print_log( "Cant find Nagios Envirionment. Exiting ....", 1 );
        exit 2;
    }

Making the simple test from #124 gave the same results, no NAGIOS_* env

define command {
         command_name                  process-service-perfdata
         command_line                  /bin/bash -c /tmp/environ.sh
         }

> cat /tmp/environ.debug
BASH=/bin/bash
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
BASH_CMDS=()
BASH_LINENO=([0]="0")
BASH_SOURCE=([0]="/tmp/environ.sh")
BASH_VERSINFO=([0]="4" [1]="2" [2]="46" [3]="2" [4]="release" [5]="x86_64-redhat-linux-gnu")
BASH_VERSION='4.2.46(2)-release'
.....

enable_environment_macros option is set to 1 in main config

Can you please help to sort out this issue? Thank you in advance!

[dougnazar]

Looks like this was dropped in the conversion to use workers for the performance data (45681cba1).

This adds it back in, but I'm not sure of the implications of doing that. It might have been dropped for a reason.

diff --git a/xdata/xpddefault.c b/xdata/xpddefault.c
index 3b05e05e..e7b1eb78 100644
--- a/xdata/xpddefault.c
+++ b/xdata/xpddefault.c
@@ -340,7 +340,7 @@ int xpddefault_run_service_performance_data_command(nagios_macros *mac, service
        log_debug_info(DEBUGL_PERFDATA, 2, "Processed service performance data command line: %s\n", processed_command_line);

        /* run the command */
-       wproc_run(WPJOB_SVC_PERFDATA, processed_command_line, perfdata_timeout, NULL);
+       wproc_run(WPJOB_SVC_PERFDATA, processed_command_line, perfdata_timeout, mac);

        /* free memory */
        my_free(processed_command_line);
@@ -381,7 +381,7 @@ int xpddefault_run_host_performance_data_command(nagios_macros *mac, host *hst)
        log_debug_info(DEBUGL_PERFDATA, 2, "Processed host performance data command line: %s\n", processed_command_line);

        /* run the command */
-       wproc_run(WPJOB_HOST_PERFDATA, processed_command_line, perfdata_timeout, NULL);
+       wproc_run(WPJOB_HOST_PERFDATA, processed_command_line, perfdata_timeout, mac);

        /* free memory */
        my_free(processed_command_line);

[filosof86]

Hi @dougnazar

Thank you! So we can use this patch but there is no guarantee it won't break something else. Did I get it right? Is there anybody who can also take a look at this to clarify if it's safe?

TIA

[dougnazar]

Thank you! So we can use this patch but there is no guarantee it won't break something else. Did I get it right? Is there anybody who can also take a look at this to clarify if it's safe?

I'm fairly sure it won't break anything else. All it does is pass the environment to the worker process, same as all the rest of the calls in the file. I guess it's possible you could exceed the size of the environment, that is warned about in the comments, but that affects all workers. I was surprised to note that the environment isn't cleared on startup, saving only a few key variables, to help avoid that. Been toying with adding an option to to that.

I was more worried about if exposing those variables to the perf programs is/was a security issue.

[ericloyd]

I'll be honest - I haven't done a full review of what this touches or what else might touch it, but Nagios Core 4 came out in....2012, I think? I have a vague memory of being at the Nagios World Conference watching it be announced. LOTS of things changed between 3 and 4. If you're just now moving from Nagios Core v3 to v4, you may find a lot of other things that don't behave as you expect them to, or not at all. There were major improvements in the scheduler and other optimizations, but there may have been a reason that this particular code was not added to v4. Unfortunately, all of those people aren't here anymore to ask (easily).

So just beware - as I'm sure you are - this may fix your problem but cause others, or it may fix your problem and cause things to slow down, or it may fix your problems and print money from your CD drive. Your mileage may vary. :-) In the meantime, I'm going to see if I can track down the person who made the commit and see if he remembers why it wasn't added then.

[sawolf]

Is there anybody who can also take a look at this to clarify if it's safe?

In your case, you should probably just try the patch and see if your perfdata processing command does what you want it to do. I can say that it doesn't look like macros_to_kvv does anything destructive to the mac pointer, and that's the only thing wproc_run is doing with it, but I haven't ever had to investigate that code deeply. My guess would be that the original programmer copied and pasted the wproc_run line from somewhere else and didn't think about the NULL at the end, but I can't give you a guarantee of anything.

[sawolf]

703 seems to be related

[filosof86]

Hi guys,

Thank you for your answers! I'll give a patch a try as soon as I can. Then will see how it goes with the rest of the things.

[filosof86]

Hi,

I've applied a patch provided by @dougnazar and so far so good. Will inform you if any issues arise.

Thanks!