Service variable not in command line

Icinga 2
1

i have a service definition that uses a nest of if else statements which is picked up correctly in the service object BUT the command object does not honor the values as arguments.

service.conf:

 vars.hface = if ( host.vars.version == "2.x" ) {
         ["em1","em2","p3p1","p3p2"]
      } else if ( "core-hosts" in host.groups ) {
             ["em1","em2","em3"]
          } else if (!( "core-hosts" in host.groups )) {
             ["em1","p1p2"]
      } else {
         ["em1","em2"]
      }

command.conf:

arguments = {
  "-s" = "$server$"
  "-u" = "$user$"
  "-i" = {
      value = "$hface$"
      repeat_key = true
      skip_key = false
     }
}

doing an “inspect” - the service shows the vars as correct but the actual command line does not use these values. i’ve tried several things including bouncing the satellites as well as the masters but to no avail.

we have an HA master-satellite cluster running version: r2.11.2-1

has anyone else experienced a similar situation where command is not using arguments from the service definition?

2

Hello,

nearly correct :slight_smile: it should look like the one bvelow or you can also do some DSL magic

if ( host.vars.version == "2.x" ) {
    vars.hface = ["em1","em2","p3p1","p3p2"]
} else if ( "core-hosts" in host.groups ) {
    vars.hface = ["em1","em2","em3"]
} else if (!( "core-hosts" in host.groups )) {
    vars.hface = ["em1","p1p2"]
} else {
    vars.hface = ["em1","em2"]
}

Regards,
Carsten

1 Like
3

it’s not the issue with the logic in the service definition - the vars from the service are not being using by the command definition. for example, a host that’s not version 2.x and has core-hosts in it’s host.group has [“em1”,“em2”,“em3”] in the list of service vars - but the command line is using [“em1”,“p1p2”]. clearly something is missing between service and command.

4

Hi Pete,

I tried to reproduce the problem and created a checkcommand, service and so on.
Your example worked like a charm.

I made a dummy script which just outputs the passed arguments:
Without group set, the output was:

-i em1 -i p1p2

With set group:

-i em1 -i em2 -i em3

So maybe the variables are overridden elsewhere?

Could you verify by

icinga2 object list ...

(or a REST-api-call) that your values are not changed elsewhere?

E.g.:

icinga2 object list --type Service --name your_host*your_servicename

And look for modifications of

* vars
  * hface =

Something like:

% = modified in ...

Oh, I forgot. I had similar problems, caused by variable override.

Greetings.

5

right - the “modified” is from the service conf file - which i would expect since those are/should be correct; but the command is using the “else” value.

some further testing today reversing the “if” statement has incorrect values in the service object. could there be an issue where the conditional test is treating true as a string instead of a boolean?

@homerjay - how did you resolve the var being overwritten?

6

oh here’s something unusual - on the master the vars.grouping which has the host.groups are correct so the service object should be correct BUT on the satellites they’re incorrect.

master:

 * vars
    * grouping = [ "all-hypervisor", "so1-hosts", "core-hosts" ]
      % = modified in '/etc/icinga2/zones.d/satellite-so1/services-hypervisor.conf', lines 26:3-26:29

satellites:

  * vars
    * grouping = [ ]
      % = modified in '/var/lib/icinga2/api/zones/satellite-so1/_etc/services-hypervisor.conf', lines 26:3-26:29
7

Hi.

Just for completeness:
As far as I remember (sorry, it happened about 2 years ago) the variable value was accidentally set twice.

Greetings.

8

Hi Pete,

can you diff the files from master and satellite? I think your satellite does not get all informations needed. Maybe the variable is defined is filled in a other zone then the satellite has access to it.

Regards,
Carsten