pfBlockerNG-Devel v3.1.0_1 is up
-
Make sure you reload your feeds after updating.
-
The problem I has with the update (from 3.1.0) was Unbound didn't restart. Had to manually restart it. Update script issue?
-
@lohphat Its like that always. It has never restarted after an update.
-
@cool_corona said in pfBlockerNG-Devel v3.1.0_1 is up:
Its like that always. It has never restarted after an update.
Yeah, it's a silly thing.
During the last update, from v3.1.0 to v3.1.0_1 I actually followed the pfSense update messages, and tailed system.log and resolver.log at the same time.
Right at the start, the update process remove the exiting python script by re creating a unbound.conf file without that python file.
That restart works well.At the end of the pfblockerng update, any my pfSense systems, some 2 minutes later, "somewhere" the Resolver is restarted.
The one and only log line is !
<28>1 2022-01-13T09:23:31.861451+01:00 pfsense.local.tld unbound 83099 - - [83099:0] warning: unbound is already running as pid 94410.the result is :
The already running process (the one without any pfBlockerNG stuff) = 94410 is 'killed'.
The new one, 83099 , bails out.result : no more unbound process.
The solution is easy :
hit the red play button. Issue solved.
At that moment, the GUI (login) access will be painfully slow .... the GUI needs DNS to work - and it doesn't at that moment.
I'm saying this to myself right now, and for the last xx months : I really should have a look at the upgrade process, and locate the exact moment when this happens.
I have doubt that it is a pfBlockerNG issue. pfBlockerNG just needs the resolver to restart when it finishes. The pfSense update process is doing that restart .... and it fails 'something'. -
@gertjan However that's not what's expected when you update a package -- you should not have to clean-up and manually restart a service after an update. The install/update script should leave the system functional after the update without intervention.
-
@lohphat said in pfBlockerNG-Devel v3.1.0_1 is up:
However that's not what's expected when you update a package ...
What do you mean ?
The upgrade/re-install script should leave the system in a working state ? Right ! I would say : of course.
It is expected that the system behaves correctly when you upgrade. It (often ?) doesn't.@lohphat said in pfBlockerNG-Devel v3.1.0_1 is up:
you should not have to clean-up and manually restart a service after an update.
I'm not cleaning up. Doing close to nothing. I just clicked on the button "upgrade pfBlockerNG" because a new version was available. That's not cleaning.
I was also tailing, because I wanted to have the possibility to so what happens when en eventually why, as "leaving the resolver dead in the water" is happening when you upgrade pfBlockerNG.You can do the same thing right now yourself.
I guess there is a there is a condition : you must be using the "Python mode".
If so, click on upgrade or, if it is already on the latest version : re install pfBlockerng-devel :
upgrade or re install is actually the same thing.
You probably wind up having the resolver process is a stopped state. This means : no more DNS. -
@gertjan You completely misinterpreted literally EVERYTHING in my post.
-
@lohphat said in pfBlockerNG-Devel v3.1.0_1 is up:
@gertjan You completely misinterpreted literally EVERYTHING in my post.
Strange, but possible.
@lohphat said in pfBlockerNG-Devel v3.1.0_1 is up:
The problem I has with the update (from 3.1.0) was Unbound didn't restart. Had to manually restart it. Update script issue?
DNS stopped when pfBlockerng was upgraded. You had to restart it. Me too. Many forum posts intentioned that also.
What did I not understand ?My posts were about looking why this happens. I didn't make progress yet.
-
Redmine issue:
https://redmine.pfsense.org/issues/11398 -
Ok, nice.
A bit of a hammer approach, though.I still wonder why unbound refuses a simple TERM signal, send initially, just a couple of lines above.
-
G Gertjan referenced this topic on
