Confused about variables

Hello I have the following situation:

I define an array of strings in a variable called services which are used by check command:

object Host ... { = ["apache2", "exim4", "postgresql"]     

Checking this with icinga2 object list give me the expected result:

# icinga2 object list --type=host --name="...*"
  * vars
    * services = [ "apache2", "exim4", "postgresql" ]

However I’ve got host object where i dont see this variable in icingaweb2 and also the check command does not know about the variable. I have no idea how I am supposed to debug this if icinga2 object lists reports these variables and icingaweb2 is running on the same host. Anybody knows about the internals here?

From what i have observed until now (i may be wrong tought), the “icinga object list” command will read configuration even if it has not been commited, in other words, what you may read is configuration currently not active in icinga.

To make sure your configuration has been pushed and is active, you can use the icinga console on your master or satellite (in this last case, make sure to have the api user you need defined on it), by using the console you can check at runtime what’s in icinga :

ICINGA2_API_PASSWORD=mypassword icinga2 console --connect ‘https://root@localhost:5665/

Then inspect your var for the host you are interested in :


If it happens your host still have not the vars properly set, then make sure icinga properly get the configuration.
First check that your staging configuration is valid :

icinga2 daemon -C

Then you can restart.
If you still dont have your vars, i’d then advise you to check debug logs, to enable them use

icinga2 feature enable debuglog

you can learn more about icinga console and troubleshooting here :

1 Like

Thank you very much. This was really helpful!

Somehow i had “vars” and “original_attributes.vars”. This is probably due to an variable set by an API call. I ended up setting the variables using icinga2 console like so:

get_host("myhost") = [ "apache2", "mariadb" ]

I dont think setting directly your var through debugging console is a viable solution for long term, if you want your modification written definitively, you should make sure icinga gets the conf from your host definition and understand where is the error if it doesn’t take it based on debug logs/config check.

Also, about the original_attributes, it is used by icinga to store the previous value in case you or icinga would want to restore vars.

An external script assigns vars.vm_host to VMs and adds a dependencies accordingly.
As far as I understand it is the expected behavior that I can not alter the config through /etc/ once I used the API to modify an object:
Once you modify an object through the API its package changes from _etc to _api. Therefore any definition in /etc/ is ignored as the object was altered through the API.
Setting the variables through the console makes them persistent as they are a new stage of _api.

These configs are stored somewhere in the filesystem in an _api folder (I cant recall where exactly right now). They are an exact copy of the _etc config plus the changes done through the API on run time. As they are stored persistently i can no longer alter /etc/.

Somebody with more insights may proof me wrong on this.

All of this was done to make things like director work.

I see your point, thanks for clarifying :wink:

Actually, i would rather say that what you push by api overrides configuration you would make in /etc/, which is a bit different.

During an icinga restart/config check, The modifications previously made on a already existing object (doesn’t matter where it is declared) at runtime are stored in /var/lib/icinga2/modified-attributes.conf and are then compiled along with others config directories (/var/lib/icinga2/api/packages/, /etc/icinga2/, …) to create the object in icinga memory.

From what i have observed, /var/lib/icinga2/api/zones/*/_etc is updated with modifications made in /etc/icinga2/zones.d/, it is an internal staging directory for /etc/icinga2/zones.d configuration as an internal package, configuration in in is not evaluated in config check, but object related are declared as belonging to _etc package.

The modifications made thought the package system are stored in /var/lib/icinga2/api/packages/<package_name>/.
More specifically, objects declared or created from api are defined under in /var/lib/icinga2/api/packages/_api/

So, your modifications are persistent as long as you dont delete the related objects or use the restore_attribute() function (undocumented function, usable only from console) which will erase modifications written in modified-attributes.conf.