On 01/11/2013 07:21 PM, Paul Dubuc wrote:
> Daniel Wittenberg wrote:
>>
>> On Jan 11, 2013, at 11:08 AM, Andreas Ericsson wrote:
>>
>>> On 01/11/2013 02:43 PM, Ton Voon wrote:
>>>>
>>>> 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?
>>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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().
>>>>>
>>>>> 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.'
>>
>> Really? I can't think of the last time I ran into a setup that the only
>> way to use a check/script was as environment variables. It's way more
>> efficient, and I think easier, to just pass the few params you normally
>> need as command-line options. Even for things like Oracle I just set local
>> env options in the script or use one of the scripts that lets you pass in
>> what ORACLE_HOME and stuff should be.
>>
>
> I set enable_environment_macros to 0 to avoid the overhead mentioned. For
> command that need environment variables set, we put them in the command object
> definition. For example, setting LD_LIBRARY_PATH:
>
> define command{
> command_name gatewayTest
> command_line \
> LD_LIBRARY_PATH=$USER31$/omni/$_SERVICE_OMNI_VERSION$/lib \
> $USER32$/bin/gatewayTest \
> -S $SERVICEDESC$ -t $_SERVICE_TIMEOUT$ \
> $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$
> }
>
> Will this not work in Nagios 4?
>
Ah. Actually, it won't, but it's fairly easily fixed. I'll get on that
on monday. Or tomorrow if it rains in sweden.
It might work to do
/bin/sh LD_LIBRARY_PATH=$USER31$/...
but I'm not entirely sure.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: ae@op5.se