@Patch Yes, I have just confirmed that it is related to early DNS registration

@Pizzamaka said in unbound stops and won't start again + high cpu:

What still puzzles me is why starting unbound through UI does not work whereas running pfblocker update does start unbound.

Not 100% sure, but it could be that when killed unbound leaves behind its PID file in /var/run/. A shell script could potentially just unilaterally delete any existing unbound PID file before attempting to restart it. That's just a guess on my part, though, as I have not looked at the code in the pfBlockerNG scripts.

When you attempt to restart the DNS Resolver from the GUI, do you see anything in the pfSense system log at that time mentioning a PID file for unbound? If you do, that would validate my guess.

Now that pfSense® Plus software version 24.03-RELEASE is out this development category has been retired.

New threads should be created in appropriate categories for any issues on 24.03. Mods can move threads out of this category into more suitable categories if someone needs to continue an old thread, or link to a thread here from a new thread instead.

@geoffb I can confirm that the parsing of the NTP block is buggy and we can reproduce it on all the uses cases. For the moment, the NTP field is not functional.

@bob-dig said in Proposed to upgrade to beta 23.05.b.xxxx, but not following the beta branch:

Maybe some sort of check for free space can be implemented in the future.

There is a an open bug for that internally but that's likely to be solved be adding features such as: https://redmine.pfsense.org/issues/13740

If you get the message, there's likely a disconnect somewhere regarding the NDI. Please contact TAC with your current NDI and pfSense+ order number (or serial number if on Netgate hardware) to sort it out.

Just want to say I resolved the issue for those who might be experiencing the same thing.

I deleted the limiters I had from before the upgrade, recreated them and it fixed the issue.

https://www.reddit.com/r/PFSENSE/comments/vqhbzw/psa_i_had_to_delete_and_recreate_traffic_limiters/
Apparently people had issues with bringing limiters through the upgrade.

Bummer.
I was really looking forward to sending you wonderful people some $$ for the CE to 22.01 upgrade.

I'm doing the home personal now for the home system. I'd also legitimately be able to say home lab.

Not sure what TAC light is...but it is also free.

Please give us an option to pick so that I can send $50-100 or something your way. Home Lab or TAC light sounds like a good place that I could reasonably convince the wife to spend a little money. I just don't want to spend $400 a year on support on the full version when I have zero intention of wasting your time by asking for support. :)

13th of April, 2021

Back to monitoring the WAN link. It is not resetting any more like before. The issues below appeared when I was streaming AOD last night. Working with XFinity to maybe correct these issues.

Mon 4/12/2021

18:59:30 MONITOR: WAN_DHCP has packet loss, omitting from routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|13.267ms|1.276ms|33%|down|highloss

18:59:46 MONITOR: WAN_DHCP is available now, adding to routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|15.906ms|5.549ms|20%|online|loss

18:59:57 MONITOR: WAN_DHCP has packet loss, omitting from routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|16.688ms|7.034ms|25%|down|highloss

19:00:01 MONITOR: WAN_DHCP is available now, adding to routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|15.823ms|5.291ms|14%|online|loss

19:00:04 MONITOR: WAN_DHCP has packet loss, omitting from routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|27.761ms|31.182ms|30%|down|highloss

19:00:12 MONITOR: WAN_DHCP is available now, adding to routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|17.575ms|7.674ms|10%|online|none

19:13:36 MONITOR: WAN_DHCP has packet loss, omitting from routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|18.989ms|11.389ms|33%|down|highloss

19:13:38 MONITOR: WAN_DHCP is available now, adding to routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|17.675ms|10.165ms|20%|online|loss

21:25:23 MONITOR: WAN_DHCP has packet loss, omitting from routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|15.089ms|5.734ms|21%|down|highloss

21:27:26 MONITOR: WAN_DHCP is available now, adding to routing group Failover

8.8.8.8|24.XX.XX.XX|WAN_DHCP|14.49ms|5.424ms|16%|online|loss

All PFSense functions appear to work OK except for not seeing VPN status on Dashboard.