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

[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 !

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 ?

	Fred.