Project

General

Profile

Actions

Bug #11398

open

pfBlocker upgrade hangs forever

Added by Renato Botelho almost 2 years ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Category:
pfBlockerNG
Target version:
Start date:
02/10/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
23.01
Affected Version:
Affected Plus Version:
Affected Architecture:

Description

It was first reported at https://redmine.pfsense.org/issues/10610#note-11 but since it never happened again with any other package I'm almost sure it's not the same root cause of #10610.

It needs to be investigated and fixed.


Related issues

Has duplicate Bug #11632: unbound service not restarted on pfBlocker-devel install/reinstallDuplicate03/07/2021

Actions
Has duplicate Bug #12996: DNS Resolver needs to run manually after pfBlockerNG-devel package upgradeDuplicate

Actions
Actions #1

Updated by andreas vesalius almost 2 years ago

Also, the bigger issue as the pfblocker-devel package manager upgrade will complete, is that unbound fails to restart and eventually must be manually restarted after this in order to have a fully functioning system for anyone using the dns resolver.

Below is how the pfblocker developer explained this problem.

“ During pkg installation of pfBlockerNG, unbound is stopped and restarted. Once on de-install and again on re-installation. There is a regression in pkg-static that causes any executables that are run within the pkg-static environment to lead into a Defunct (zombie) state. When pkg-static completes, Unbound is left in a non-running state and needs to be started manually. This issue can also cause the pkg installer to delay for several minutes and appear crashed.‘

Actions #2

Updated by Renato Botelho almost 2 years ago

andreas vesalius wrote:

Also, the bigger issue as the pfblocker-devel package manager upgrade will complete, is that unbound fails to restart and eventually must be manually restarted after this in order to have a fully functioning system for anyone using the dns resolver.

Below is how the pfblocker developer explained this problem.

“ During pkg installation of pfBlockerNG, unbound is stopped and restarted. Once on de-install and again on re-installation. There is a regression in pkg-static that causes any executables that are run within the pkg-static environment to lead into a Defunct (zombie) state. When pkg-static completes, Unbound is left in a non-running state and needs to be started manually. This issue can also cause the pkg installer to delay for several minutes and appear crashed.‘

it would be nice if you can share the steps to reproduce. What items of pfBlocker config I need to enable to trigger this issue. Also, does it happen every upgrade?

Actions #3

Updated by andreas vesalius almost 2 years ago

At work, but this has happened with every pfblocker upgrade since trialing pfSense 2.5 and then moving to pfblocker 3.0. Not sure if it affects initial install, but every point release upgrade of pfblocker via the package manager regardless if it is upgraded alone, with another package or as part of a pfSense upgrade. Most recently occurred when I moved to 2.5 rc and that had an associated pfblocker 3.0.0_8 to _9 upgrade with it.

Actions #4

Updated by Viktor Gurov about 1 year ago

  • Has duplicate Bug #11632: unbound service not restarted on pfBlocker-devel install/reinstall added
Actions #5

Updated by Viktor Gurov about 1 year ago

for some reason unbound does not terminated in 30s:

Stopping Unbound Resolver.............................. ( <- 30 seconds )
Additional mounts (DNSBL python):
   Mounting: /lib
   Mounting: /dev
   Mounting: /var/log/pfblockerng
   Mounting: /usr/local/share/GeoIP
Starting Unbound Resolver... completed [ 01/17/22 15:41:39 ]

fix:
https://github.com/pfsense/FreeBSD-ports/pull/1136

Actions #6

Updated by Viktor Gurov 10 months ago

  • Has duplicate Bug #12996: DNS Resolver needs to run manually after pfBlockerNG-devel package upgrade added
Actions #7

Updated by Renato Botelho 10 months ago

  • Assignee deleted (Renato Botelho)
Actions #8

Updated by Christian McDonald about 1 month ago

  • Status changed from New to Feedback
  • Assignee set to Christian McDonald
  • Target version set to 2.7.0
  • Plus Target Version set to 23.01

Issue here has to do with pkg(8) hardening that prevents it from spawning long-lived processes. pkg(8) uses procctl to change the default process repear from init to itself, which means any processes that pkg starts are not going to be adopted by init which is standard operating procedure for daemons.

I have patched pkg in our ports tree to work around this limitation while we continue to investigate a better service management solution.

Actions

Also available in: Atom PDF