[squid-users] squid.service with Type=Notify is not always reliable (Arch Linux)

[Alex Rousskov]

On 9/1/20 10:27 AM, Amish wrote:

> Accepting ... connections at ...  message came almost immediately (in 1
> second).
> Sep 01 06:40:05 foo squid[8446]: Accepting SSL bumped HTTP Socket
> connections at local=[::]:3128 remote=[::] FD 27 flags=9

OK, so you are not using SMP Squid and, assuming your Squid build
supports calling sd_notify(), sd_notify() was called. We need to figure
out why it had no effect. Suggested next steps:

1. Adjust Squid to print the value of $NOTIFY_SOCKET together with the
"Accepting..." line. This will confirm that the variable is set. It
should be set. This debugging can be added without fear of producing too
much info but it is unlikely to be insightful.

2. Add some kind of sd_notify() debugging that would show us what the
first sd_notify() call was doing and when/whether systemd received the
notification from Squid. I have not researched how to do that, but I am
sure it is possible. I bet there are not enough notifications happening
on your production server to cause problems, but you should practice on
a lab server first, of course.


> Not sure that parse URL line has anything to do with this bug as
> sd_notify() was expected to happen long before that.

Right. I would only worry if that line appears every time Squid starts,
indicating some kind of automated systemd-related(?) probe/test (which
fails).


HTH,

Alex.