On 01/15/2013 12:34 PM, Ton Voon wrote:
>
> On 15 Jan 2013, at 11:12, Andreas Ericsson wrote:
>
>> On 01/15/2013 10:05 AM, Ton Voon wrote:
>>> Hi Andreas,
>>>
>>> On 14 Jan 2013, at 10:08, Andreas Ericsson wrote:
>>>
>>>> On 01/14/2013 10:30 AM, Ton Voon wrote:
>>>>> What I can't work out is how to set the env property in "define command". Can you provide some pointers and assistance?
>>>>>
>>>> Using a secondary list of key/value vectors. Since commands are usually
>>>> fewer than 500 and remain pretty static, I'd just use a command->id
>>>> indexed pointer-to-pointer list of key value vectors.
>>>
>>> I couldn't work out how to create this array. I modelled it on command_ary, but it kept segfaulting when setting this first array element. I'm sure there's a malloc required somewhere, but I couldn't see how command_ary was being initialised. In the end, I've extended the command object to include an env attribute.
>>>
>>
>> That's the forbidden solution. Objects have to be the same size in all compiled
>> versions.
>
> Why is this forbidden? Nagios 4 is not released yet, right?
>
It's not, but all modules are already updated and tested. Changing this
now would mean having to redo that coding and testing again.
If you really want to make this change, I'll have to suggest you send
patches to livestatus, NDOUtils, Merlin, mod_gearman and DNX as well,
or at least verify which of them breaks.
>> You have to make an init function for it, allocate the right amount of memory
>> and then stash the env pointers in a linked list starting at the right slot
>> in the memory index.
>
> Can I reverse the question to ask - where is this initialisation currently handled for command_ary and timeperiod_ary? I can see the my_free() calls in objects.c, but I can't see where the init is.
>
create_object_table(), called from the mktable() macro. Both live in
common/objects.c.
>>
>>> The next problem is that with an arbitrary list of environment variables, I need to pass this to the worker job creator. I can't see how to extend the wproc_* jobs, but it looks like the nagios_macros are not used. So I propose that we change:
>>>
>>> static int wproc_run_job(worker_job *job, nagios_macros *mac)
>>>
>>> to
>>>
>>> static int wproc_run_job(worker_job *job, char **env)
>>>
>>> Is this acceptable?
>>>
>>
>> Since macros aren't used, yes, although it would be better to pass a
>> key value vector directly, since we can avoid a ton of strlen() calls
>> that way and also allow any random values to be passed to the command
>> calls, which allows for future extensions.
>
> I'm more comfortable doing it as an array of strings, though I can look at kvvec.
>
kvvec_addkv(kvv, "env", );
Compared to managing a list of strings, it's positively cuddly.
--
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