Re: [Nagios-devel] [PATCH] Fix default value for
Re: [Nagios-devel] [PATCH] Fix default value for
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