Bug#945002: systemd: Dependencies not honoured at boot, so a service doesn't start

[Michael Biebl]

Control: reassign -1 squid
Control: retitle -1 squid should use /run/squid.pid

Am 21.11.19 um 11:52 schrieb Fred Boiteux:
>     Thanks Michael for your advices !
> 
> Le 21/11/2019 à 11:27, Michael Biebl a écrit :
>> Am 21.11.19 um 10:49 schrieb Michael Biebl:
>>
>>> As you can see, the problem is, that you have a resolvconf hook which
>>> tries to start squid.service way too early during boot. It's not
>>> directly systemd which schedules the start of the service.
>>> Since those hook scripts are prone to cause deadlocks, invoke-rc.d will
>>> use "ignore-dependencies" during early boot to mimic the SysV behaviour.
>>>
>>> I suppose if you delete that script /etc/resolvconf/update-libc.d/squid
>>> your problem should be gone.
>>>
>>>> if  [ -d /usr/sbin ] && [ -d /run/systemd/system ] && systemctl -q
>>>> is-active squid || [ -f /var/run/squid.pid ] ; then
>>>>     invoke-rc.d squid reload
>>>> fi
> 
> I've checked script file /etc/resolvconf/update-libc.d/squid on my
> system : it's a Debian 10 Buster, with squid package version
> 4.6-1+deb10u1, and its content is only :
> 
> 
> #!/bin/sh
> 
> PATH="/usr/sbin:/usr/bin:/sbin:/bin"
> 
> # Make squid aware of changes to resolv.conf
> # Avoid reload before /usr is mounted
> if [ -d /usr/sbin ] ; then
>    invoke-rc.d squid reload || true
> fi
> 
> 
> So the tests you have in your version didn't appear there ! It's from
> the latest squid package version (4.9), and I found it's come with this
> commit :
> Resolvconf: Avoid reload before squid.pid is available (Closes: #911325)
> 
> I wondered why I didn't view this bug report when looking at squid
> package, perhaps because it was noted as fixed (but in testing/unstable
> version only !).
> I tried so to copy this new version of this script on my system, and
> reboot... But the squid service didn't start on next boot :-(
> 
>>> Is /var/run a symlink to /run ?
> …
>>> squid really should use /run/squid.pid for its service to avoid this
>>> kind of problem. /run is guaranteed to exist during the whole lifetime
>>> of the system and available during early boot.
> 
> I've checked that /var/run is actually a link to /run, it's OK, but as
> you say, perhaps I've some cruft in /var directory of the root
> partition, it's quite difficult to see as I can't unmount the /var
> partition without access to the system's console…
> But I tried to fix the squid.service about this problem :
> 
> -- squid.service.old   2019-11-21 11:43:33.965354518 +0100
> +++ squid.service       2019-11-21 11:43:11.529140405 +0100
> @@ -13,7 +13,7 @@
> 
>  [Service]
>  Type=forking
> -PIDFile=/var/run/squid.pid
> +PIDFile=/run/squid.pid
>  ExecStartPre=/usr/sbin/squid --foreground -z
>  ExecStart=/usr/sbin/squid -sYC
>  ExecReload=/bin/kill -HUP $MAINPID
> 
> And with this second update, Squid service is now booting correctly at
> boot ! :-)
> 
> 
> So to resume :
> – I've applied the fix for #911325 bug back on my Debian Buster system
> — I've updated the squid.service to use /run instead of /var/run ; my
> previous trial to enrich the dependencies to actually depend on /var
> mount wasn't required once the first point was fixed !

Right, so stable needs two fixes:
- A backport of #911326
- squid.service (and related hook scripts) to use /run/squid.pid

The latter should be fixed in unstable first though and can then be
backported.

> I'll report that progress on the squid bug I commented (#932593),
> however, I wonder if these fixes could be backported to the Buster suite ?

This is a question the squid maintainer has to answer. But in general
I'd say a bug fix like this should qualify for a stable release.


I'm going to reassign this bug report to squid, asking it to use
/run/squid.pid

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20191121/b99f3742/attachment.sig>