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.
