On 2025-12-28 Adam Thompson wrote:
I think you might be able to suppress the error output by redirecting the outer shell's stderr to /dev/null, but I'm struggling to see where either grep instance could possibly see its stdout vanish without warning! I'm not 100% convinced the error message is actually coming from grep, rather I think it might be coming from the shell instead.
That could very well be. The shell saying "grep is gonna have this problem, and I'm telling you"?
I would also not use nmap for this, I suspect fping will be far
Doh, now you tell me! :-)
Ya, fping does exactly what I need without all the tricks. I never knew it existed. It's in Fedora's repos so that's good enough for me.
I settled on: fping -q -r 1 -t 1 -X 1 -S ... { # clear! }
Some other options look promising but as soon as you start fiddling with counts and timeouts it switched into "run a lot, output a lot" mode for some reason, even with -q. I'll have to just assume the defaults for these things are sane.
Yup, run in an always-running script, started from systemd for autorestarts, runs every few mins and restarts things that seem busticated and systemd didn't/can't handle.
Yes, this one bit is to paddle-resuscitate the lan/nic should the 25+ hosts all suddenly disappear. Usually due to whacked out or dying NIC, or whacked out or dying switch(/port). Rarely hits, tries a fix, and notifies me to look into it.
As for the spurious pipe error, I'll safely ignore until I ever need to try that self-killing hack again!
Thanks!