Am 21.11.19 um 09:10 schrieb Fred Boiteux: > Hi, > > Please find the output of 'systemctl show squid.service' in 'info1' > attached file, > and the output of 'journalctl -alb' in 'info2' one. > > Thanks for your help, > Fred. > > [I send this e-mail again, seems that my first answer didn't reach > Debian bug system]
Thanks for the log. nov. 18 09:30:26 Deve2m resolvconf[358]: Job for squid.service failed because the control process exited with error code. nov. 18 09:30:26 Deve2m resolvconf[358]: See "systemctl status squid.service" and "journalctl -xe" for details. nov. 18 09:30:26 Deve2m resolvconf[358]: invoke-rc.d: initscript squid, action "reload" failed. nov. 18 09:30:26 Deve2m kernel: EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) 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 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. -- 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