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

[Amish]

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

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.

Hence, to eliminate all race conditions involving lookup of the client's 
unit and attribution of notifications to units correctly, 
sd_notify_barrier() may be used. This call acts as a synchronization 
point and ensures all notifications sent before this call have been 
picked up by the service manager when it returns successfully. Use of 
sd_notify_barrier() is needed for clients which are not invoked by the 
service manager, otherwise this synchronization mechanism is unnecessary 
for attribution of notifications to the unit.

Example 5. Eliminating race conditions

When the client sending the notifications is not spawned by the service 
manager, it may exit too quickly and the service manager may fail to 
attribute them correctly to the unit. To prevent such races, use 
sd_notify_barrier() to synchronize against reception of all 
notifications sent before this call is made.

            sd_notify(0, "READY=1");
                  /* set timeout to 5 seconds */
                  sd_notify_barrier(0, 5 * 1000000);


I am not sure if this is related. I have no clue about sd_notify(). But 
can it be the reason?

Amish