[squid-users] squid.service with Type=Notify is not always reliable (Arch Linux)
rousskov at measurement-factory.com
Tue Sep 1 13:47:08 UTC 2020
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: Starting Squid Web Proxy Server...
> Sep 01 06:41:34 foo systemd: squid.service: start operation timed out. Terminating.
> Sep 01 06:42:06 foo systemd: squid.service: Failed with result 'timeout'.
> Sep 01 06:42:06 foo systemd: 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
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?
More information about the squid-users