Catch up on the latest product updates, best practices, and expert insights from the Checkmk Conference #12 – Watch the livestream recordings now

Werk #16931: MTR agent bakery rule: several entries per destination

Component Agent bakery
Title MTR agent bakery rule: several entries per destination
Date Sep 17, 2026
Level Trivial Change
Class Bug Fix
Compatibility Compatible - no manual interaction needed
Checkmk versions & editions
3.0.0b1
Not yet released
Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT
2.5.0p15
Not yet released
Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT
2.4.0p38
Not yet released
Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT
2.3.0p51
Not yet released
Checkmk Pro, Checkmk Ultimate, Checkmk Ultimate MT

The agent bakery ruleset MTR (Matt's traceroute) (Linux) derived the section name in mtr.cfg - and with it the service name - from the Destination address alone. Configuring the same host twice, for example once with Enforce IPv4 and once with Enforce IPv6, therefore wrote the same section twice. The agent plug-in cannot parse such a file: it printed **ERROR** Failed to parse config file ... into the agent output and monitored only the first of the two entries.

When several entries share a destination address, the section name now also carries whichever of these settings differ between them: connection type (ICMP, TCP, UDP), enforced IP version (IPv4, IPv6), port, packet size, source address and maximum number of hops. Tracing om-office.de over both IP families thus yields the services Mtr to om-office.de (IPv4) and Mtr to om-office.de (IPv6) without configuring anything extra. Only the address is handed to mtr; everything from the first space onwards exists solely to name the service.

Entries that are indistinguishable in all of those settings are rejected when the rule is saved, instead of breaking the plug-in on the monitored host. The remaining settings - number of packets, minimum time between runs, interval, timeout and DNS resolution - do not take part, because they change how often or how patiently a destination is traced rather than what is traced.

A destination configured once keeps exactly the service name it has today, so existing services are unaffected. The Destination address no longer accepts spaces: host names and IP addresses do not contain any, and the space is what separates the address from the derived part of the section name.

To the list of all Werks