Project

General

Profile

Actions

Bug #11398

closed

pfBlocker upgrade hangs forever

Added by Renato Botelho almost 4 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Category:
pfBlockerNG
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
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 4 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 4 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 4 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 almost 3 years ago

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

Updated by Viktor Gurov almost 3 years 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 over 2 years ago

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

Updated by Renato Botelho over 2 years ago

  • Assignee deleted (Renato Botelho)
Actions #8

Updated by Christian McDonald almost 2 years 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 #9

Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved
  • Start date deleted (02/10/2021)
  • % Done changed from 0 to 100

This has been working since the fix went in.

Actions #10

Updated by Jim Pingle over 1 year ago

  • Plus Target Version deleted (23.01)
Actions #11

Updated by Jim Pingle over 1 year ago

  • Target version deleted (2.7.0)
Actions

Also available in: Atom PDF