Werk #22109: Service discovery no longer aborts on failed address lookup
| Component | Core & setup | ||||
| Title | Service discovery no longer aborts on failed address lookup | ||||
| Date | Sep 9, 2026 | ||||
| Level | Prominent Change | ||||
| Class | Bug Fix | ||||
| Compatibility | Compatible - no manual interaction needed | ||||
| Checkmk versions & editions |
|
Previously, service discovery aborted for a host whose IP address family is set to
IPv4 only (or IPv6 only) if its name could not be resolved and no explicit IP address
was configured. It gave up before contacting a single data source -- including the ones
that need no address at all, such as piggyback data, individual program calls, push
agents, and special agents that authenticate against an external API.
Regular checking never had this problem. That is why such a host could happily show its piggyback services in the Check_MK service, and Check_MK Discovery could report Services unmonitored -- while no discovery path was able to add them.
Discovery now behaves like checking: the sources that need an address fail individually
with a "Failed to lookup IP address" error, and the services from the sources that
succeeded are returned as usual. This applies to cmk -I / cmk -II and the service
discovery page. Bulk and periodic discovery are subject to an additional guard, see
below.
This is not a reason to leave the address family misconfigured. If a host is monitored
entirely without being contacted directly, set IP address family to No IP: its host
check then reports UP instead of DOWN, and Checkmk stops attempting name resolution
for it altogether. The IP address family tag group has gained a help text explaining
the four options and when to reach for No IP.
Bulk and periodic service discovery
Both run unattended and both may remove services, so they refuse to update a host as long
as any of its data sources reports a problem. That guard is deliberate and unchanged: such
a host is still reported as failed -- now with the message "Failed to lookup IP address
and no explicit IP address configured" -- and its services are neither added nor removed.
Setting IP address family to No IP removes the failing source and lets these two paths
discover the host as well.
Periodic service discovery was moreover affected differently from the other paths: rather
than aborting, it substituted the address 0.0.0.0, which on Linux resolves to the local
system. In unlucky cases it could discover the services of the Checkmk server itself onto
the unresolvable host. This no longer happens.
Known limitation
A host's address is looked up in more places than the discovery. The configuration
generated for the monitoring core still contains the fabricated 0.0.0.0, and so does the
address the core hands to the Check_MK service. Both still reach the local system, so
such a host can report the services of the Checkmk server itself -- in its Check_MK
service, and, with the Checkmk Micro Core, as unmonitored services in its Check_MK
Discovery service. Those services cannot be added by any discovery path, which is the
inconsistency described above, now visible from the other side.
Removing the fabricated address from the configuration generation affects the monitoring
of every host and is therefore left to a separate werk. Setting IP address family to
No IP avoids it entirely.
Also fixed
cmk -I and cmk -II now exit with 1 if the discovery of at least one host failed, and
report the data sources they could not contact. They used to print nothing but the abort
of a whole host, and exit 0 regardless. The discovery of the remaining hosts is still
carried out.
Bulk discovery no longer concludes with "Bulk discovery successful" when its own summary line says "0 succeeded, 1 failed". The result message is now "Bulk discovery finished".
A host that is not in the configuration at all is no longer discovered as if it were a
host without any services. cmk -I reports "unknown host" and exits with 1, cmk
--check-discovery reports UNKNOWN - Unknown host, and the service discovery page shows
the same error instead of an empty service list. Before, this was covered up by the failing
address lookup -- but only for hosts whose name happens to be unresolvable.