Disable checks not working

Icinga 2
1

at v2.10.5 when i disable active checks via the icingaweb2 (v2.7.0), the checks continue to run despite it showing as disabled. is this fixed in v2.11?

2

Hi,

I just tested this with Icinga v2.11.2 and Web v2.7.3 works here as expected. I click active checks to set the switch to disabled and the column Next update becomes something like expected in 55s or expected in -0m 17s if overdue.

How do you determine the checks keep running? Has your API user sufficient permissions to disable the checks?

Best regards
Michael

1 Like
3

the check is very simple - check by ssh to a host and do a date. the output keeps updating. and yes i also see “next update: expected in 25m” (the check runs every 15minutes).

4

Hi,

can you please share the config details for these objects, as well as a runtime inspection from the specific service object via the REST API?

https://icinga.com/docs/icinga2/latest/doc/15-troubleshooting/#list-configuration-objects

Cheers,
Michael

5

in the icinga2 object list i see that * enable_active_checks = true is listed.

the ApiUser for icingaweb2 has permissions = [ "status/query", "actions/*", "objects/modify/*", "objects/query/*" ]

the dashboard show it’s disabled though:

Screen Shot 2020-01-28 at 2.03.48 PM

we have an HA 2 masters set up with 2 zones each with 2 satellite servers

6

so i noticed a couple other things which may or may not help. according to the dashboard the “active endpoint” and the “icinga web endpoint” are both pointing to the secondary master; but the “inspect” as well as the object list are from the primary master (that shows active_checks = true). on the primary master we have the api.conf as

object ApiListener "api" {
  accept_config = false
  accept_commands = false
  ticket_salt = TicketSalt
}

if i go directly to the primary master dashboard and disable the active checks…it will cascade to the secondary and correctly show as “false”

so - either how do force the web endpoint and active endpoint to both be the primary OR is there a config change to accept_commands = true?

7

You need to set accept_config = true on the primary master, since this modification is treated as config change.

8

but that goes against the documentation for setting up HA master pairs.

9

Which documentation are you following?

10

HA Masters and three levels. i can’t seem to find the exact references but IIRC it was mentioned that the primary master should not receive config or commands. it may have been in an older documentation.

11

Ok, that’s possible. We have fixed a long lasting loop bug for comments/downtimes in 2.11 which allows this enablement again. A git blame likely tells that I have edited the docs :slight_smile:

That being said, the enable_config=false was only a workaround limiting acks and modified attributes when sent to the secondary master which syncs back to the primary master then. Finding that bug took me years though.

Cheers,
Michael

1 Like
12

setting accept_config = true and accept_commands = true on the primary master worked. thanks for the help.

1 Like