Hotplug event causes rc.start_packages: Restarting/Starting all packages
-
Not yet, let me re-raise it...
-
@stephenw10 any movement on this yet?
-
Not yet. I ran it past a few developers and the consensus was that restarting packages on a link state change is probably expected. However that doesn't explain the interaction with track6. And it seems completely unnecessary in many cases, such as this one.
Fixing this correctly may involve a lot more work than we have time for in 23.01. I suspect a complete review of the service start scripts is in order.
I'll try to get something opened. There's definitely a bug there somewhere, one of those behaviours is wrong.Steve
-
-
-
@stephenw10 just curious if any additional discussions have been had since your last post?
Thanks!
-
Actually this was discussed recently here: https://forum.netgate.com/topic/180783/23-05-pf-was-wedged-busy-and-has-been-reset
I'll be opening a bug for this shortly.
-
@stephenw10 Thank you!
-
Hi,
I have the same thing happening on my side, when something change, it restart packages. And of course my Wireguard tunnel is going down ... i absolutely have no clue on why it does that (wireguard not going back up).Did you figure this out yet ?
-
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 DHCP6Navigate 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 InterfaceScroll 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
-
-
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!