disk-windows not working in icingaweb2

  • Hello,

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

    Quote

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

    9745-disk-windows-not-working-png


    While the output of calling check_disk.exe directly works:

    9746-disk-windows-not-working-2-png







    Client:

    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:

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

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

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


    Server:

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

    Code
    1. [...]
    2. apply Service "disks" {
    3. import "generic-service"
    4. check_command = "disk-windows"
    5. command_endpoint = host.vars.remote_client
    6. assign where host.name == "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: https://github.com/Icinga/icinga2/issues/3159, where the output is also cut off after the :.

  • I tried to reproduce your issue but I can't.


    My Icinga Web 2 output:



    Output of the command line:



    The only way I could get such a short output was, when I set a dedicated partition to check. Have you set disk_win_path or disk_win_exclude somewhere? Maybe a view into the debug log on the windows machine is useful to see with which plugin parameters the check_disk.exe is called.

  • Quote


    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: https://docs.icinga.com/icinga…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:

    Code
    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 host.name == NodeName
    8. }

    and once like this:

    Code
    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 host.name == NodeName
    7. }


    but I get:

    Quote

    Plugin Output

    Failed to access drive at B:\


    Is it normal that there are 2 processes?:

    Code
    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
  • Your second service apply rule should work for both partitions. In your first apply rule you "override" the disk_win_path parameter with just B: and the service will only check the B: partition.


    In the default configuration the Icinga 2 Windows Agent is running with the network service account. I guess the user hasn't the right to read the B: partition and therefore the check result is failed access. Please verify if the service account has enough rights to read the B: partition or set up an own user for the Icinga 2 service with the right rights.


    I checked one of our windows host and there are also two processes of icinga 2. I don't have an explanation for this but it could be a child process of icinga2, AFAIK every check that is performed is handled in an own process.

  • 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.

  • Just for testing purposes can you change the user, that runs the icinga 2 service, to an other user or give Local System explicit rights to partition B: .


    Running the check_disk.exe from the Powershell is not the same as Icinga 2 is calling the check. When you running the check from the Powershell, you do this with your current user rights and I guess that your user has enough rights to read partition B: .

  • 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"\\");)

  • You can check that in the services.msc in the tab "Login" or "User" (don't know the exactly name have only windows hosts here with a german language installed, I have a image attached for clarifying). Please also check the rights on the partition itself.




    In my config I use only the drive letters with a colon e.g. F:

  • 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.

  • I never tried to check network drives with the check_disk.exe but I doubt that the check can handle network drives.


    Maybe the check disk_smb is a solution for you.