The specified service does not exist

Hello.

I have strange problem here. I just migrated ICINGA2 to a new host (fresh install, copied the conf-files). Everything works so far. But I have one Windows Server, where some service checks are not working and I have no idea why. The plugin output shows: “The specified service does not exist as an installed service.”

Setup:
To all Windows servers the following service check is applied:

apply Service "Trend Micro Security Agent" {
  import "generic-service"
  check_command = "service-windows"
  vars.service_win_service = "svcGenericHost"
  command_endpoint = host.vars.remote_client
  assign where host.vars.trendmicro == "true"
}

It’s one of three services (all Trend Micro related), from which i get the “does not exist” message.
There are other service checks on this host (for example MSSQL and multiple Hyper-V-Services), which run successfully. So it’s not a connection problem.

The service mentioned above is running. A local check is successful:

C:\Windows\system32>c:\ICINGA2\sbin\check_service.exe -s svcGenericHost
SERVICE "svcGenericHost" OK RUNNING | 'service'=4;;;1;7

I updated icinga on the windows server (to Icinga2-v2.14.2-x86_64.msi), but the problem remains.

Does someone has a clue, what could be wrong?

Hi @hgoetze,
just to clarify, I do imagine the steps like this:

  • The check was working correctly
  • Replacing your main Icinga 2 instance with a new one
  • reconfiguring Icinga 2 on the windows machine to talk to new (if Endpoint Name/Certificate infrastructure was replaced)
  • The check fails
  • Updating Icinga 2 on Windows
  • The check still fails

Is that correct so far? Did you change (relevant) configuration after migrating?

Hi @lorenz .

Yes. Before the migration everything was OK.
Then I replaced the main instance. I did a fresh install and then copied everything as stated here at the bottom: Debian - Icinga 2

This worked. No need for reconfiguration of the client. There are around 80 Windows and Linux servers monitored by this instance. No problems otherwise.

The check of three services on one Windows host now shows “service does not exist”. There are another eight services on the same host, where the checks are working. So no general problem on the host.

After updating Icinga on this host, I ran the node wizard. But no change.

As shown in the first post, running the check_service.exe locally on the server works. The Icinga service is running as system account (i know, it’s not recommended). So it should not be a permission issue.

All the Windows systems running the same Trend Micro endpoint protection and all the systems are setup the same way (regarding Icinga and Trend Micro)

I don’t get, what’s so special about the three services on this host. :frowning:

ok, the setup/migration sounds sane.
If you are using IcingaDB you have a “Source” tab in your Service view in IcingaWeb 2. You can find the command there which was executed.
That should be equal to the one you executed manually.

If you are using the IDO backend you have to do some work to find out what the command was (since you are not using the director).
You could either use the icinga2 console command [0] or the HTTP REST API [1] to query the service and find the actually executed command.

[0] Cli Commands - Icinga 2
[1] Icinga2 Api - Icinga 2

This “source” Tab is a cool new feature. At least for me it’s new. The old instance used IDO.

I just figured out, what’s wrong. Mid november i cloned the Windows vm. Of course it got another ip address. But it seems, the Icinga client still running on the clone (forgot to disable it) was somehow used for the checks. Or was it sending results to the master by itself?!?!
I always thought, the Icinga master tells the client running a check using the ip address given in the host definition and the client returns the result.
Seems i misunderstood the process. The old instance was running for at least 9 years. I think i have to reread the docs. :slight_smile:

Thank you for your support.

Hm, tricky.
The problem is, an agent has an identity (the NodeName constant) and, depending on your configuration, it might be trying to reach its parent on its own.
Therefore, there might have been two instances connecting to the master with the same identity and valid certificates.
Depending on which one came first it might have executed the check and the other one was blocked.
Hard to tell without seeing the setup.

The (IP) address of the Host object is not that important for that process, the host attribute of an Endpoint object is important if the master connects to the child.

OK.
I’ll check this out. Never thought about this, since it worked all theses years without problems.
Thanks again for helping.
Have a nice day!