Posts by Icinga2User

This forum was archived to /woltlab and is now in read-only mode.


    I get many emails with <Timeout exceeded.> and after a few hours with this Remote Icinga instance '...' is not connected to 'Icinga2' for the same machine and the Windows Update service. I know that Windows Update can take a while to answer, so I'm not surprised that it causes timeouts. How can I disable the timeout warning for this service check or set the timeout to a higher value for this service check?

    When I search for "timeout" /etc/icinga2# grep -riI "timeout" there's unfortunately nothing.

    My Icinga2 version:

    1. icinga2 --version
    2. icinga2 - The Icinga 2 network monitoring daemon (version: r2.7.1-1)

    Yes, I checked.

    On this Windows server there are only one native drive: C:, S: and B: are network drives, maybe that has something to do with it, because on another Windows server where there are more than one native drive, the output is correct and lists all the native drives.

    Now I'm not sure, whether the listed drives were not native drive all along and the network shares never worked in the first place.

    I just deinstalled Icinga2, deleted C:\ProgramData\icinga2 and reinstalled the Windows client again, but still the same error. So, I'm not sure if this is still because of the Windows client' faulty config. I'm also not sure if this is the Icinga2 server' faulty config then either because I installed it on a completely new VM, but since S: and B: are network shares, this could be the reason that Icinga2 process can't access them.

    Ok. So, if I wanted to add the S: and B: shares then, I could paste the output of > .\check_disks.exe (see that PowerShell image in my initial post) into a txt file (a PowerShell script run by Administrator and independently of Icinga2) and read that by Icinga2' PowerShell object CheckCommand. That's a workaround but would work (I tested it already: since the output string is the same and it comes from check_disks.exe, Icingaweb2 can parse and display it correctly). Or install Icinga2 on those servers that provide the shares in the first place.

    Since this question was not about network shares, I'll close this within the next days, if no one knows how to make the Icinga2 process able to read/access these shared network drives.

    Good question. How can I check that? > services.msc shows Icinga2 as Local System.

    I see that Icinga2 uses GetDiskFreeSpaceEx and I read that this expects X:\\ (that's with two backslashes), so I added that: vars.disk_win_path = [ "C:\\", "B:\\" ], but unfortunately still the same access error. I saw later that Icinga2 adds the \\ itself (it->append(L"\\");)

    Thanks, ok, I changed it then to vars.disk_win_path = [ "C:", "B:" ], but I still am getting: Failed to access drive at B:\.

    I checked and, as expected, the Icinga2 service runs as Local System because I use check_update.exe to check if any Windows Updates are available, which needs elevated rights.

    Calling check_disk.exe from the PowerShell lists all drives (as can be seen in my screenshot I posted in my initial post), so it should work (again, I also remember that I could see all the drives some time ago in icingaweb2). Really interesting that it's not working.


    The only way I could get such a short output was, when I set a dedicated partition to check.

    Yes, this could be it, because the output does not start with DISK OK - free space:Total ... and I also found an image with basically the same output as I have:…onitoring-windows-plugins where the output stops after a : and this seems to be the normal output. I'm very sure I had all the disks show up when I first installed Icinga2 on this Windows client. I assume this is a setting-thing now.

    I tried adding the disks C: und B: manually to both Icinga2 server and the Windows client:

    Once like this:

    1. apply Service "disks" {
    2. import "generic-service"
    3. check_command = "disk-windows"
    4. vars.disk_win_path = "C:"
    5. vars.disk_win_path = "B:"
    6. command_endpoint = host.vars.remote_client
    7. assign where == NodeName
    8. }

    and once like this:

    1. apply Service "disks" {
    2. import "generic-service"
    3. check_command = "disk-windows"
    4. vars.disk_win_path = [ "C:", "B:" ]
    5. command_endpoint = host.vars.remote_client
    6. assign where == NodeName
    7. }

    but I get:


    Plugin Output

    Failed to access drive at B:\

    Is it normal that there are 2 processes?:

    1. PS C:\ProgramData\icinga2> get-process icinga2
    2. Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
    3. ------- ------ ----- ----- ----- ------ -- -----------
    4. 303 40 27504 37080 134 1,34 2324 icinga2
    5. 135 11 19232 23804 83 0,06 13300 icinga2


    the output of disk-windows in icingaweb2 seems to be cut off after the ::


    DISK OK - free space:C:\ 8157 MB (13%):


    While the output of calling check_disk.exe directly works:



    The services which are set in the default services.conf on the Windows client aren't working at all BTW, so I added this disk service explicitly to my other win-services.conf:

    1. [...]
    2. apply Service "disks" {
    3. import "generic-service"
    4. check_command = "disk-windows"
    5. command_endpoint = host.vars.remote_client
    6. assign where == NodeName
    7. }
    8. [...]

    , commented this service in services.conf as it's not working anyway:

    1. /*apply Service for (disk => config in host.vars.disks) {
    2. import "generic-service"
    3. check_command = "disk-windows"
    4. vars += config
    5. }*/


    And am calling this Service from my other win-services.conf from the Linux server:

    1. [...]
    2. apply Service "disks" {
    3. import "generic-service"
    4. check_command = "disk-windows"
    5. command_endpoint = host.vars.remote_client
    6. assign where == "SERVER 07"
    7. }
    8. [...]

    It works so far that it delivers the correct size and space left, but only for drive C:, but there are other drives as you can in the PowerShell.

    It used to work when I setup this Windows client for the first time some months ago, but after several removes and re-installs something broke as it looks.

    One related bug I could find is this one:, where the output is also cut off after the :.

    Thanks. I indeed just copied object User "icingaadmin" and changed the email, and since the copy is already in the same groups, it works and I didn't need to change anything else.

    I have email notifications working successfully and I get email to Now I'd like to add a second email.

    icinga2# cat conf.d/users.conf

    But when I change email from

    1. email = ""


    1. email = [ "", "" ]

    I don't get any syntax errors, but I don't receive emails anymore either. I tried different syntaxes, but unfortunately none is working.

    I remember I had it once working where I just added a second email like above, but it looks like the syntax was different.

    What is the correct syntax?


    since my last posts my Client-Master setup has been working great (both the clients and the master are in the same local network).

    Now this setup needs to be extended to a Client-Satellite-Master setup, where the current Master will become a Satellite I think, and where the new Master is running on an AWS EC2 VM, and where the Satellite then pushes data to the AWS Master. Question: Is it possible that the Satellite pushes data to the AWS Master or must the AWS Master also be able to contact the Satellite? I.e.: Are push-/ pull-only setups possible as all?


    1. Master
    2. / | \
    3. Client01 Client02 Client03


    1. Master internet
    2. | |
    3. Satellite local
    4. / | \ |
    5. Client01 Client02 Client03 local

    I already tried to change the current master into a satellite by running # icinga2 node wizard on it (the zones.conf is modified when running node wizard, so I re-added the clients back), but the clients wouldn't connect to the satellite, even after re-running their GUI node wizard setup and deleting the old /pki certs.

    Is there maybe a certain order, like that first a master setup, then connecting the satellite to it and then the clients to the satellite? (I tried that also, but again, the clients wouldn't connect to the satellite, and the master and satellite don't see each other.)

    I followed…er/distributed-monitoring BTW.

    Here is my current master's zones.conf from the current working Clients-Master setup:

    And the conf.d/win-hosts.conf:

    How to change this working master-clients setup into a master-satellite-clients setup?

    It works now.

    AFAICanSee the only thing I did is to:

    1.) added the following to conf.d/services.confaon the server:

    1. apply Service "Windows Updates" {
    2. import "generic-service"
    3. check_command = "update-windows"
    4. command_endpoint = host.vars.remote_client
    5. vars.update_win_warn = true
    6. vars.update_win_crit = true
    7. assign where == "DOMAIN-NAME1"
    8. assign where == "DOMAIN-NAME2"
    9. }

    and 2.) after I got Access denied, I changed the icinga2 service from Network Services to Local System Accounton the Windows clients.

    3.) If I also remember correctly, I also did a > icinga2 node wizard on the one Windows client, but I'm not sure if this is required because if I remember correctly, I setup the other Windows clients without using this command (I used this command because the one Windows client couldn't be found because of a case-sensitive spelling mistake, so this command indeed might not have been necessary).

    I tried again the way I already setup 2 other Windows hosts (AFAIR is didn't work the first time) and instead as described here, I entered:

    Instance Name: icinga

    Host: | the IP, not "icinga"

    and the setup went successful. The problem is that only the services ping4 and ping6 work. The other are UNKNOWN and I get:

    Remote Icinga instance '' is not connected to 'icinga', despite that I entered this host to zones.conf and conf.d/hosts.conf, as done with the other 2 hosts.

    EDIT: Found it: The "error" was in the spelling (this host's domain name was in small letters (contrary to the other hosts))

    Hm, there's no type A /IPv4 address in there, but pinging either the IPv4 or icinga / client name from client to server and vice versa works.

    Yes, I entered the full DNS name.

    The server has a DNS name and pingng and and other services (not icinga related) using this server work.

    Maybe it helps someone: I just had a

    1. critical/TcpSocket: getaddrinfo() failed with error code 11001, "Der angegebene Host ist unbekannt. "
    2. critical/pki: Cannot connect to host 'icinga' on port '5665'
    3. critical/cli: Failed to fetch certificate from host

    when adding a new Windows client. In…ndows_setup_wizard_02.png I entered the IPs instead of DNS name, since the DNS name could not be resolved. This is probably not optimal as a DNS name is more fixed.

    Nevermind, this does not work (the Windows client setup seemed to be successful but the server shows UNKNOWN on all services except ping4 and ping6) :D

    Glad it works.

    Yes, I always (well, just for a few days since I'm a beginner) edited commands.conf AND services.conf, where a apply Service "any name" {[...] check_command = "name1" [...]} uses a object CheckCommand "name1" {[...]}. But I just noticed that it seems that no apply Service in services.conf on the client is needed for a powershell script to work, only in the Icinga2 server's services.conf.

    Maybe it's still needed, I don't know, but I removed the apply Services from the Windows clients and hopefully will see if they are needed on the clients. Maybe someone here knows the answer.


    I noticed that among other check_*.exe files in C:\Program Files\ICINGA2\sbin, check_update.exe is also setup by default by the icinga2 installer, but it's not used/activated by default. On the Windows client I added to C:\ProgramData\icinga2\etc\icinga2\conf.d\services.conf:

    1. apply Service "update" {
    2. import "generic-service"
    3. check_command = "update-windows"
    4. assign where == NodeName
    5. }


    and > restart-service icinga2 but unfortunately the service doesn't apprear in /icingaweb2.

    The Icinga2 server does contain a update-windows object CheckCommand:

    The Windows client works with the some of other services setup by default, however, I want to add check_updates to it.


    I want to monitor a button in a GUI tool and check whether the button was pressed. If the button is pressed, it's shown greyed out.

    I tried > Get-Process PROCESSNAME| format-list * and at first it seemed that the Handles value would work as it changed when the button was greyed out and changed back to the original value when the button was not greyed out. It worked for a while, but later the Handels value increased by 1 and so monitoring the Handles value seems out of the question.

    Is there a tool which would list all the detailed informations of a running process including buttons, so that a button change would be possible to readout and be monitored?

    (In case someone is interested in reading a certain value from the get-process:

    $Handles = get-process PROCESSNAME | select -last 1 -ExpandProperty Handles)