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

Werk #16932: MTR: report why mtr failed instead of showing no data

Component Checks & agents
Title MTR: report why mtr failed instead of showing no data
Date Sep 18, 2026
Level Trivial Change
Class Bug Fix
Compatibility Compatible - no manual interaction needed
Checkmk versions & editions
3.0.0b1
Not yet released
Checkmk Community, Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT
2.5.0p15
Not yet released
Checkmk Community, Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT
2.4.0p38
Not yet released
Checkmk Community, Checkmk Pro, Checkmk Ultimate, Checkmk Cloud, Checkmk Ultimate MT
2.3.0p51
Not yet released
Checkmk Community, Checkmk Pro, Checkmk Ultimate, Checkmk Ultimate MT

When mtr refused to run - an unresolvable destination, missing raw socket privileges, an unusable bind address - the agent plug-in threw the message away together with the unusable report file. The service Mtr to ... went UNKNOWN with Insufficient data: No hop information available and there was nothing, anywhere, saying why.

mtr writes its complaints into the very report file the plug-in reads. That text is now carried to the service: a run that produced no hop reports mtr failed: <what mtr said>, still in state UNKNOWN.

A destination that used to work and then breaks is the second half of this: the plug-in kept reporting the hops of the last successful run, so the service stayed OK while nothing was being measured any more. Those hops are still reported - throwing them away would only replace one silence with another - but the service details now say Data is from the last successful run, the latest one failed: .... The state is unchanged, so no service starts alerting because of this werk.

The message travels behind the hop data in the agent output, so an updated agent works with an older Checkmk site and vice versa. Both sides are needed for the message to show up though - the agent plug-in to send it, the site to display it. Neither a re-discovery nor a change to the agent bakery ruleset is required.

The message is remembered between agent runs, so it stays visible for destinations that are configured with a minimum time between runs.

Two further glitches in the same code are fixed on the way. A malformed hop line discarded the whole destination instead of just that line. And the plug-in's own diagnostic about an unparsable status file was mistyped in a way that could break parsing of the entire section.

To the list of all Werks