Hotplug event causes rc.start_packages: Restarting/Starting all packages
-
You only need to set that one time to prevent it restating packages if an internal interface bounces.
-
@stephenw10
Hey, my tunnel went down ... again
This time to restart it i had to remove port configuration for my tunnel under VPN > Wireguard > Tunnel > Edit Tunnel > Listen Port.
If that help anyone or for any debugging.
I´l have a look at your workaround -
Any errors logged? Did it not even try to come back up?
The trackv6 thing might prevent it restarting due to that particular interface bouncing but it should still restart. So you have two issues happening here I'd suggest.
Steve
-
@stephenw10 i'll have a look at logs when having physical access to my Pfsense box .. because yet again my tunnel is down ...
Note that i have yet to try what you say. -
Just curious, was a redmine opened for this or does it not meet the threshold?
-
Not for the trackv6 issue. Yet. I'm going to revisit it for 23.09 though because to me it seems like there must be a bug there.
-
Thank you, Stephen
-
-
Not sure if this is the same problem mentioned here, so I created a different thread:
https://forum.netgate.com/topic/182625/packages-restarting -
-
@stephenw10 said in Hotplug event causes rc.start_packages: Restarting/Starting all packages:
https://forum.netgate.com/topic/180783/23-05-pf-was-wedged-busy-and-has-been-reset
Was a bug ever opened on this? I understand that this may seem like a fairly innocuous problem for most, but there are various circumstances that can cause the simple cycling of a non-WAN interface, which don't involve a WAN IP changing... so having all of the pfSense services restart (including HAproxy) whenever that happens is particularly problematic for those of us using pfSense in HA environments. This is especially true for those of us running websites behind HAproxy, as HAproxy gets restarted whenever an interface cycles, interrupting web users' sessions. For example, we just experienced an odd issue where our pfSense sync interface connecting our primary and failover firewalls was down, despite there being a link, and admin up status. Cycling the interfaces on both firewalls fixed the issue, but resulted in new_wanip being needlessly triggered, and restarting everything. So fixing our pfSync connection (something that should've been innocuous) resulted in an interruption of services for our users.
I'm hoping the IPv6 "tracking" solution you mentioned above as a workaround for this works for us and other people experiencing this issue... but still, given that it's been almost a year now, I hope we can at least get a bug opened, so this issue can get visibility, and at least have a chance of getting prioritized in the backlog. Thanks!
-
Hmm, probably not since that workaround exploited a bug that is now fixed: https://redmine.pfsense.org/issues/14756
So the particular issue you see in an HA setup is that the pfSync Interface is directly connected and hence is link cycled. Yet despite both ends being statically configured and most services not listening to that everything is restarted?
That does seem like something that could be excluded.