Control: tags -1 + moreinfo On Monday, May 18 2020, I wrote:
> On Monday, May 18 2020, I wrote: > >> On Sunday, May 17 2020, Amos Jeffries wrote: >> >>> Since the /run/squid directory now depends on systemd squid.service file >>> for existence the 'squid' binary cannot be run. >>> >>> This breaks all non-systemd init systems, multi-tenant installations, >>> and scripts running the squid binary for control commands. >>> >>> >>> When started without the "service squid" systemd-specific command Squid >>> produces: >>> >>> 2020/05/17 17:07:48| FATAL: failed to open /run/squid/squid.pid: (2) No >>> such file or directory >>> exception location: File.cc(190) open >> >> Thanks for the report. Can you please provide more info on how you're >> starting the service? Are you using the /etc/init.d/squid script? > > Also: I assume you have squid's apparmor profile enabled. If that's the > case, then could you please try to reload its profile? > > # apparmor_parser -r /etc/apparmor.d/usr.sbin.squid > > and try again? > > If this works, then it's the same bug I'm experiencing after upgrading > squid, and I have a fix for that. Just a few more details I've been able to gather this afternoon. I'm using a Debian sid VM where I installed sysvinit to replace systemd. I wasn't able to reproduce the problem reported above, even after activating the apparmor profile before upgrading. If you look at the /etc/init.d/squid script, you can see that the startup function does create the /run/squid/ directory. I will need more info to investigate this bug. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
signature.asc
Description: PGP signature
