Re: [Nagios-devel] [PATCH] Fix default value for

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

Re: [Nagios-devel] [PATCH] Fix default value for

Post by Guest »


On 11 Jan 2013, at 12:17, Andreas Ericsson wrote:

> On 01/10/2013 11:31 PM, Ton Voon wrote:
>> However, even with this set to true, it looks like Nagios 4 doesn't
>> set the envvars. In host/service checks, it looks like no envvars are
>> set. Is there a technical reason why this is not done, or is this a
>> bug?
>>=20
>=20
> The technical reason is twofold: I'm lazy, and environment macros =
cause
> a lot of additional problems for anything but very small systems, =
while
> providing a mediocre benefit at best.
>=20
> The problem people have been seeing with Nagios 3 where certain checks
> fail to run when they add an extra service to a servicegroup is due to
> environment macros being enabled and the environment space being =
eaten.
>=20
> To enable them again means transferring the entire environment to the
> designated worker process, parsing it from there and setting it in a
> new heap which we pass to execvpe().
>=20
> Since we will always pay *all* overhead for all checks but very, very
> few of them use more than one or two of the variables set, the benefit
> really isn't worth the additional overhead.

I think this "bug" is a blocker for upgrading to Nagios 4 since certain =
checks/notification scripts/event handlers expect the environment =
variables to be set.

> A different (and far niftier) idea is to use "env" statements for
> commands, where one can determine certain variables to pass through
> the environment. That way we'd pay very little overhead and only for
> the variables people actually want exported via the environment. It
> would also make it possible to set certain environment variables for
> plugins that require them (like many of the oracle checks do).

I completely agree about the performance overhead.

The reason I dislike parsing at the command line is that "funny =
characters" can interfere with the processing or affect the command =
executed. Passing through the environment is a lot more consistent.

> So.. yes, it's a bug, but consider environment variable support of the
> current notion (all or nothing) to be deprecated and scheduled for
> removal in Nagios 5 with a more powerful way to control environment
> variables replacing it.

I've had a look at how the environment is handled in the workers and it =
does look like there is some support for it, though a FIXME says it =
hasn't been enabled. However, I've managed to get it working so that I =
can pass some envvars from the main process to the worker, and it gets =
set at time of execution. I need some help to make it work for all of =
the macros though and I'm not sure if there are some limits breached in =
the kvvec_addkv() calls.

So I propose that:
1) enable_environment_macros=3D1 passes all the environment data in =
the wproc_run_job() to retain backwards compatibility
2) an env_macros field is available in all objects to define =
specifically which environment macros. This is a comma separated list, =
defaulting to ALL for backwards compatibility

I'm happy to do some of this work, but will require agreement on the =
design and some technical assistance.

Ton






This post was automatically imported from historical nagios-devel mailing list archives
Original poster: ton.voon@opsview.com
Locked