Werk #22396: Service discovery: "Update service labels" and "Update discovery parameters" now affect only changed services
| Component | Checks & agents | ||
| Title | Service discovery: "Update service labels" and "Update discovery parameters" now affect only changed services | ||
| Date | Sep 28, 2026 | ||
| Level | Trivial Change | ||
| Class | Bug Fix | ||
| Compatibility | Compatible - no manual interaction needed | ||
| Checkmk versions & editions |
|
The Setup service discovery page offers two host-wide actions, "Update service labels" and "Update discovery parameters". Both are meant to act only on the services whose discovered labels or parameters have drifted from what is stored -- the ones the page classifies as "changed" -- and to leave every other service untouched.
Instead, both actions retargeted every service on the host -- except the disabled ones -- to "monitored". On a host that also had undecided or vanished services this had visible effects in the same request:
- every undecided service was silently accepted into monitoring, and
- every vanished service was written back as monitored, taking its freshly discovered values.
The resulting pending change looked like an ordinary "Saved check configuration
of host ... with N services", so the additional services were easy to overlook.
The same defect was reachable through the REST API, via the only_service_labels
mode of the service discovery start endpoint, even on a host with no changed
services at all.
Both actions now act only on services that are already monitored and whose discovered values changed: "Update service labels" writes their new labels and "Update discovery parameters" writes their new parameters. Undecided, vanished and disabled services are left untouched. On clusters a service's node entries follow the cluster: an action run on a node leaves them as stored -- no longer reviving or re-adopting them -- and their values are refreshed only when the action is run on the cluster itself.