Hotplug event causes rc.start_packages: Restarting/Starting all packages
-
Does it eventually reconnect? Does it reconnect manually? What do you do to recover?
-
Navigate to Interfaces > WAN
Even if you do not use IPv6 environment, set IPv6 Configuration Type to DHCP6
Navigate to the Interface that is causing the restart of packages (you may have to do this on more than one interface)
Set IPv6 Configuration Type to Track Interface
Scroll down under Track IPv6 Interface section and set IPv6 Interface to WAN
This will keep Wireguard from restarting. It will, however, restart IPSec tunnels so if you have those it won't be of any help.
Another workaround is to setup a switch on that interface so it thinks it is always up
I believe a bug is going to be /has been opened up for this issue
Hope this helps!
-
@stephenw10 hi,
My Wireguard tunnel isn't restarting, unless i restart manually Wireguard service on PfSense ... which is a little bit complicated when i don't have acces to Pfsense -
@32G3LiQxu8
That would be cool for my Wireguard tunnel, but if i destroy my colleague IPsec tunnel ... he won't be happy -
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
-
X Ximulate referenced this topic on
-
Not sure if this is the same problem mentioned here, so I created a different thread:
https://forum.netgate.com/topic/182625/packages-restarting -
C coolspot referenced this topic on
-
@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.
