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

[Matus UHLAR - fantomas]

>
>> > "kill -9" will definitely leave some things in an odd state. Try the
>> > double-kill first.

>On Sun, 13 Mar 2022 18:38:05 -0400
>Alex Rousskov <rousskov at measurement-factory.com> wrote:
>> 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!

On 13.03.22 18:49, Dave Blanchard wrote:
> 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. 

this is how squid works - it needs to cleanly close connections etc.

you can lower shutdown_lifetime option in config file 

> 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.

try different browser probably. I don't know if chromium has option not to 
fetch images etc.

> 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.

either shut it down correctly so it can start again, or don't shut it down 
and then expect not being able to start.

> 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.

this makes much sense and has already been explained.
starting with invalid configuration ignorec means possible unexpected 
behaviour.

according to what you wrote above, I am sure you don't want to squid fetch 
full content of interrupted transactions just because config directives were 
not read properly.


>  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,

kill -9 DOES kill the damn thing, and it doesn't allow the damn thing 
cleaning up the mess.

https://porkmail.org/era/unix/award#uuk9letter

> 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?

this discussion makes no sense.
if you don't like how squid works, try e.g. wwwoffle.

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name.