Cannot uninstall nor upgrade squidGuard
-
...the GUI and cli report:
[2.4.5-RELEASE][admin@fw2.r0x.on]/root: pkg-static remove squidGuard
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):Installed packages to be REMOVED:
pfSense-pkg-squidGuard: 1.16.18_5
squidGuard: 1.4_15Number of packages to be removed: 2
Proceed with deinstalling packages? [y/N]: y
[1/2] Deinstalling pfSense-pkg-squidGuard-1.16.18_5...
Removing squidGuard components...
Menu items... done.
Services... done.
Loading package instructions...
Deinstall commands... done....then just hangs forev0r and will eventually fail.
I've rebooted multiple times, and have tried:
killall pkg-static
pkg-static upgrade -f
(which hangs on squidGuard)
..and https://docs.netgate.com/pfsense/en/latest/packages/fixing-a-broken-pkg-database.html
...which did not appear to help. -
Open another tab for the GUI and stop the squidGuard service (and maybe squid for good measure)
-
Couldn't do that because somewhere in the previous attempts the GUI entry was removed.
You know what DID work ??
...removing it from Service Watchdog....sigh
Thanks for the reply :)
–------------------------------------------------
2.4.3-RELEASE (amd64)
built on Mon Mar 26 18:02:04 CDT 2018
FreeBSD 11.1-RELEASE-p7
VM in ESXi 5.5
1 x 1000baseTX (WAN)
1 x 1000baseTX (LAN) -
@DigitalJer said in Cannot uninstall nor upgrade squidGuard:
...removing it from Service Watchdog
Put "Service Watchdog" on the" to be removed" list.
Service Watchdog should be used if an over night temporary solution is needed.
It should not be used on a daily bases. It will cause grief, or worse. -
@DigitalJer said in Cannot uninstall nor upgrade squidGuard:
Couldn't do that because somewhere in the previous attempts the GUI entry was removed.
You know what DID work ??
...removing it from Service Watchdog....sigh
Thanks for the reply :)
No offense to the package creator, but Service Watchdog is kind of a dumb package. What I mean by that is the package is blissfully unaware of what is happening on the firewall in terms of a package being uninstalled maybe, or paused for an update, etc. Service Watchdog simply greps the running processes, and if the daemon name for a monitored package disappears (as in that daemon stopped), Service Watchdog will immediately attempt to restart it by calling the startup script for the service. Obviously, when a package is trying to shut itself down for an ordered uninstall or update, Service Watchdog blindly attempting to restart it right in the middle of that will cause issues such as locked files and so forth.
Service Watchdog causes many issues with the IDS/IPS packages, Snort and Suricata, for this same reason. The package does not understand how to tell when Snort or Suricata is automatically restarting due to a rules update cycle. Service Watchdog simply checks for the daemon, sees it is not running at that instant and immediately attempts to restart it. Very likely Snort or Suricata was already trying to start itself, so now you can end up with two identical processes running on the same interface!
So I'm with @Gertjan here. Remove the Service Watchdog package. You don't need it!
-
@bmeeks said in Cannot uninstall nor upgrade squidGuard:
No offense to the package creator, but Service Watchdog is kind of a dumb package.
Hey, that's me! ... But I take no offense because it is a giant kludge. It does have some rare but specific useful purposes, but it gets used as a sledgehammer more often than not.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp said in Cannot uninstall nor upgrade squidGuard:
@bmeeks said in Cannot uninstall nor upgrade squidGuard:
No offense to the package creator, but Service Watchdog is kind of a dumb package.
Hey, that's me! ... But I take no offense because it is a giant kludge. It does have some rare but specific useful purposes, but it gets used as a sledgehammer more often than not.
Yeah, I didn't mean it was "dumb" as in useless or has no purpose. I was referring to its logic for determining when a service is stopped. It just has one piece of data to make a decision on (the monitored daemon is running or not running) and it has to act based on that. It can't tell when certain external events are the cause for a service being temporarily "down" such as updates or reinstall sequences.
-
@jimp said in Cannot uninstall nor upgrade squidGuard:
Hey, that's me! ... But I take no offense because it is a giant kludge. It does have some rare but specific useful purposes, but it gets used as a sledgehammer more often than not.
You... you... klutz
Jokes aside sometimes I wish the package would be hidden in some "debug/expert" options only. I see that popping up far too often for my liking. Often the cultprits aren't even sure why they installed it or it's because of misunderstood problems (restarts of unbound because DNS errors etc.)Can't we hide it from the UI and only allow it to be installed hands-on via shell/ssh?
Or just throw a big red box of test above it so it's understood, that it's only a workaround but no "solution"?
But as for the OP problem: is the "new" pkg tool somehow more sensible for running services? We had our share of problems after updating to 2.4.5p1 and afterwards, too and most of them are due to pkg deadlocking or stalling with packages, especially the big ones like FRR, Squid, pfBlocker?
As a side note: It would be nice to have a tool like service restart, that could use trigger/event conditions like other internal processes do e.g. WAN down/renewed IP, gateway fail, service xy restart, package (re/un)install, sync, whatever ;) That would be more in the way of the "shellcmd" package but it would make quite a few things easier to handle :) Especially a hook like "after any change written to config.xml" would be incredibly nice for doing some backup'py stuff.
