[squid-users] Bug: 'squid -k interrupt' quits on config file error, fails to kill process

[Dave Blanchard]

On Sun, 13 Mar 2022 18:38:05 -0400
Alex Rousskov <rousskov at measurement-factory.com> wrote:

> > "kill -9" will definitely leave some things in an odd state. Try the 
> > double-kill first.
> 
> Just to add: kill -9 will not kill SMP Squid workers and other kid 
> processes. To a large degree, Squid will just keep running as if nothing 
> happened -- that signal cannot be caught and processed specially by the 
> receiving Squid process. Do not use "kill -9 `cat pidfile`" if you are 
> using SMP Squids!

It turns out double kill with a SIGTERM, besides being rather inelegant, doesn't do the job either. It takes its sweet ass time--a few seconds--to exit. Who said I wanted the proxy, busy or not, to keep running and finish what it's doing? The entire point is for it to stop IMMEDIATELY! ESPECIALLY if it's currently busy!

One of the main purposes for Squid on my system is to proxy Chromium, which likewise has the brilliant design of continuing to load page elements (on my extremely low bandwidth connection with a quota) when I've clearly told it to STOP NOW. The point is to put a hard, immediate stop to it, via killing the proxy.

So is there a signal that can be sent which is the exact equivalent of squid -k interrupt? The only reason I was using that command in the first place is because 'kill' wasn't doing the job correctly.

Why, oh why, does the config file have to be 100% valid, when the request is to simply STOP the damn thing? That makes no logical sense. Deciding to crash on some obscure malformed config directive while simply giving the command to STOP is NOT the right way to handle the situation. Forget about "not enough resources to add that feature." That is how it should have been designed from day one! So basically, "not enough resources to fix what we designed wrong in the first place." To be fair, I guess you just initially assumed everyone would want the proxy to finish up what it's doing before quitting. But that's not true in every case.

What is actual use of the pidfile to the end user, when kill -9 does not actually kill the damn thing, but actually fucks things up worse by leaving zombie processes running in the background--and SIGTERM doesn't do the job either, even when asked twice? Why the hell aren't all signals being forwarded to the child process(es), or otherwise architected so death of the controlling process brings down the whole thing?

-- 
Dave Blanchard <dave at killthe.net>