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

Alex Rousskov rousskov at measurement-factory.com
Wed Sep 2 14:21:08 UTC 2020

On 9/2/20 3:01 AM, Amish wrote:
> On 01/09/20 8:31 pm, Alex Rousskov wrote:
>> 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.

> Ok. I will try above. But here is a note from "man sd_notify" about race
> condition that MAY occur.

> Conversely, if an auxiliary process of the unit sends an sd_notify()
> message and immediately exits, the service manager might not be able to
> properly attribute the message to the unit, and thus will ignore it,
> even if NotifyAccess=all is set for it.

Since the Squid worker that calls sd_notify() keeps running under normal
conditions (and if it _does_ exit quickly, then its notification should
be indeed ignored!), the above caveat seems irrelevant to me.

Disclaimer: I do not know much about systemd and sd_notify(). I am just
reading the documentation you found and applying it to Squid.


More information about the squid-users mailing list