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 have to add here, that the script uses invoke-rc.d squid reload which is translated to systemctl reload --job-mode=ignore-dependencies squid.service This is merged with the start request of squid.service. The net effect is, that the start request now ignores dependencies as well. This is surprising behaviour. If you want to read more about this, see https://github.com/systemd/systemd/issues/10464 > Is /var/run a symlink to /run ? > Keep in mind that you have a separate /var which is (late during boot) > mounted over /var. I suspect you have a stray /var/run/squid.pid on your > / file system which confuses the above the check, makes it think squid > is running and triggers are reload of the service. > > 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. This still holds true. This bug report should probably be reassigned to squid asking the service to be changed to use /run/squid.pid -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
