Error in apply services after upgrade to v2.11


I hope everything ok,

Yesterday i made an upgrade from 2.7 to 2.11, after a rough beggining the system start up but i had to disable every service check, right now icinga is just pinging by default but no personalized checking memory, disk, services, users, etc, etc is done.

If I enable services config page i get this error when running icinga2 daemon -C:

critical/config: Error: Validation failed for object ‘!memory’ of type ‘Service’; Attribute ‘command_endpoint’ : Checkable with command endpoint requires a zone. Please check the troubleshoot

The zone of every endpoint is setup in zones.conf this was working smotthing before upgrade, but i dont know what i have to change to make this work again without change something wrong.

This is the service:
apply Service “memory” {
import “generic-service”
check_command = “memory-windows”
check_period = “24x5”
vars.memory_win_warn = “5%”
vars.memory_win_crit = “0%”
command_endpoint = host.vars.remote_client
assign where host.vars.os == “Windows”

//if i comment this line "command_endpoint = host.vars.remote_client " i dont get the above error, but i get this

Plugin Output
execvpe​(/usr/lib64/nagios/plugins/check_​memory.​exe) failed: No such file or directory, obviously is not checking on remote machine and the plugin for windows is not in icinga master.

There is something wrong with my setup?

I have every host in a config file in conf.d so with services, zones is in zones.conf, and everything seems to be right in icinga2.config, i’ve read something about zones.d but it didn’t work when move everything into this folder, and change the folder in icinga2.conf

Hope help me find the error or point me in the right direction.

Hi & welcome,

I’d assume the conf files for your agents are now in wrong place (as there was a change in icinga2) e.g. when you use satellites they have to be in zones.d/\<satellite zone>/. Could you please described your setup and more details about your conf files?

Hi Ronald, thank for the reply and welcome,

This is an actual look into the settings

the root folder

Inside conf.d

I did separate servers, and devices in diferents folder for a better understand, inside of each folder there are two files one for declare host, and one for declare services.

This is in spanish
Servicios.conf = services.conf
servidores.conf = servers.conf

inside servidores.conf

object Host “servername domain com” {
import “generic-host”
address = “”
address6 = “::1”
vars.remote_client = “servername domain com”
vars.os = “Windows”
vars.servicio = “”
vars.nombre = “ggg”
vars.notification[“mail”] = {
groups = [ “” ]

inside servicios.conf

apply Service “memory” {
import “generic-service”
check_command = “memory-windows”
check_period = “24x5”
vars.memory_win_warn = “5%”
vars.memory_win_crit = “0%”
command_endpoint = host.vars.remote_client
assign where host.vars.os == “Windows”


/************************* Master ***********************/

object Endpoint NodeName {

object Zone ZoneName {
endpoints = [ NodeName ]

object Endpoint “servername domain com” {
host = “”

object Zone “servername domain com” {
parent = ZoneName
endpoints = [ “servername domain com” ]

every server has this config

I only have one master, and all the servers report to it.

folder zones.d was created but has nothing inside just readme file


const NodeName = “master domain com”

/* Our local zone name. */
const ZoneName = “master domain com”

include “constants.conf”


  • The zones.conf defines zones for a cluster setup.
  • Not required for single instance setups.
    include “zones.conf”


  • The Icinga Template Library (ITL) provides a number of useful templates
  • and command definitions.
  • Common monitoring plugin command definitions are included separately.


  • This includes the NSClient++ check commands. These command definitions
  • are required on a master node when a client is used as command endpoint.


  • The features-available directory contains a number of configuration
  • files for features which can be enabled and disabled using the
  • icinga2 feature enable / icinga2 feature disable CLI commands.
  • These commands work by creating and removing symbolic links in
  • the features-enabled directory.
    include "features-enabled/


  • Although in theory you could define all your objects in this file
  • the preferred way is to create separate directories and files in the conf.d
  • directory. Each of these files must have the file extension “.conf”.
    include_recursive “conf.d”

That’s all the configuration i have and as i said we only have one master and all the clients report to it.

If you need something special just tell me, i did read something about zones.d and master file but i wasn’t pretty sure how it works.

Best practice for your setup is described here. With your current configuration your host objects are defined without zone assignment. Hence, you need to create a directory with the name of your master zone in zones.d and move your conf files with host objects to this directory.

Another hints:

  • You don’t need vars.remote_client = “servername domain com”
  • it’s enough to use command_endpoint = in service objects instead
  • For pasting conf files etc. please follow these formatting tips

Thanks Roland,

So just to be sure about this, i have to create a directory call “ZoneName”, in zones.d.

Thanks for the tips.

No, ZoneName is a constant. You need its content master domain com as directory name.

sorry, but i just want to get this straight before making any change and help anyone else, im not into icinga2 all the time so im kinda new with this release.

I have to create a master zone in zones.conf
then change parent to master in endpoints

create a directory master inside zones.d
then move all my folder and files inside conf.d to directory master inside zones.d

modify icinga2.conf to disable conf.d and enable zones.d

thanks in advance, i will try do it above if you have any comments please reply.

No, please read my tips again.