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

[Alex Rousskov]

On 9/1/20 2:32 AM, Amish wrote:

> I have frequently observed an issue with squid.service but I am not able
> to detect the real cause. As mostly it works but sometimes does not.

> What happens is squid starts correctly, but systemd does not seem to be
> getting the notification from squid that it has started.

> Sep 01 06:40:04 foo systemd[1]: Starting Squid Web Proxy Server...
> Sep 01 06:41:34 foo systemd[1]: squid.service: start operation timed out. Terminating.
> Sep 01 06:42:06 foo systemd[1]: squid.service: Failed with result 'timeout'.
> Sep 01 06:42:06 foo systemd[1]: Failed to start Squid Web Proxy Server.

When did your Squid workers print their "Accepting ... connections at
..." message(s)? Those messages will give you the approximate time of
sd_notify() calls made by Squid workers.


> Squid cache.log shows no error w.r.t. notify and seems to start correctly.

AFAICT, Squid code does not report sd_notify() failure to notify iff
that failure was due to an unset $NOTIFY_SOCKET variable. The first
sd_notify() call in Squid also unsets $NOTIFY_SOCKET variable (in the
calling worker). However, I cannot explain why that variable would be
unset during the first sd_notify() call _sometimes_.

Perhaps systemd is confused by concurrent notifications coming from
multiple workers?

Can you enable 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?

Alex.