Bug #7790
closed
dpinger / code using it, falsely defines a down gateway as up after dpinger gets restarted.
Added by Pi Ba over 7 years ago.
Updated about 7 years ago.
Category:
Gateway Monitoring
Affected Architecture:
All
Description
dpinger / code using it, falsely defines a down gateway as up after dpinger gets restarted.
Or maybe the code that uses it wrongly defines it as down.. as dpinger itself only tells it measured no loss and no latency sofar. while actually it didnt measure anything those first few seconds after it starts.
This adds and seconds later removes the gateway from gatewaygroups while nothing changed with regard to the gateway its monitoring.
Anyhow a pullrequest is waiting that evades this issue: https://github.com/pfsense/pfsense/pull/3763
- Status changed from New to Feedback
PR has been merged, thanks
Works for me :). But then again, i made the patch. Would be weird if it didn't 'fix' my reported issue..
Question that remains is if this is the proper workaround.? Or should apinger be changed to more clearly report it hasn't gathered enough data yet to give usable results.?
Checked with version:
2.4.0-RC (amd64)
built on Mon Sep 11 21:38:52 CDT 2017
FreeBSD 11.0-RELEASE-p12
- Status changed from Feedback to Resolved
So 'file exists' check returns true, but then it doesn't exist.. Wondering how that can be ;) well i probably dont want to know.. (can of worms..)
Because during the sleep while it's in the loop, the file can disappear if something happens in the background.
Thats kinda what i meant with "i dont want to know", as even though now the check and usage are always only microseconds apart 'something' might still happen in the background.
But yes the chance of it happening likely did decrease so much that no-one will encounter it again (anytime soon).
Adding 'locks' around lots of things to avoid such situations 100% would likely cause more issues than it solves.. and even then 'something' might happen that was not planned. a crash of dpinger or out of memory, a corrupted memory bit or something else unforeseen :)
I should probably leave it at that and hope that pfSense 3.0 has a different framework that avoids most of these background 'unexpected' changes.
Anyhow thanks for improving it!
Yes it was definitely weird, I saw it on maybe 3/12 test systems (so ~1/4) but not every boot either. They're all OK with the current change though.
Also available in: Atom
PDF