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?
signature.asc
Description: OpenPGP digital signature