On Saturday, May 23 2020, Amos Jeffries wrote: > On Mon, 18 May 2020 18:27:04 -0400 Sergio Durigan Junior wrote: >> On Monday, May 18 2020, I wrote: >> >> > 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. >> >> I submitted >> https://salsa.debian.org/squid-team/squid/-/merge_requests/13 to fix the >> latent bug that I am experiencing when upgrading to the latest squid >> (unstable) and when the apparmor profile is enabled. >> > > Good catch. Thanks. > > > But that is not related to this problem. Apparmor profile and all > package install/configure is fine for access to the /run/squid directory > in latest packages. > > The issue is seen with manually run commands directly using the squid > binary. Debian init scripts are caught by systemctl and do not show > issues - though I expect it will be seen on Blends or installs without > systemd at all (eg Devaun).
BTW, I made sure to remove systemd before trying using the /etc/init.d/ script. > The commands to replicate are: > > 1) the command documented as required to initialize caches before > starting Squid: > > # squid -z -f /etc/squid/cache.cnf > 2020/05/23 19:11:39| FATAL: failed to open /run/squid/squid.pid: (2) No > such file or directory > exception location: File.cc(190) open > > # tail -n 20 /var/log/squid/cache.log > 2020/05/23 19:11:39| FATAL: failed to open /run/squid/squid.pid: (2) No > such file or directory > exception location: File.cc(190) open squid should be in charge of creating the directory tree it needs to use. I don't think this issue is systemd-specific: when the user is not running systemd, the sysv init script will also create /run/squid/ if it doesn't exist. The only difference, as you pointed below, is that systemd will automatically delete the directory if the service is stopped, which is a sensible default IMO. If we really want the directory to be kept, it's possible to use RuntimeDirectoryPreserve=yes. > 2) command required to start multiple instances of Squid (may be run by > a custom init script): > > # squid -n gateway -f /etc/squid/gateway.cnf > # squid -n cache -f /etc/squid/cache.cnf > # tail -n 20 /var/log/squid/cache.log > 2020/05/23 19:10:32| FATAL: failed to open /run/squid/squid.pid: (2) No > such file or directory > exception location: File.cc(190) open > > 2020/05/23 19:10:32| FATAL: failed to open /run/squid/squid.pid: (2) No > such file or directory > exception location: File.cc(190) open > > # Right. BTW, while doing these investigations I also found that the sysv init script doesn't really change the user/group ID when invoking the squid daemon, which will lead to failures even if /run/squid/ exists. I'll submit an MR soon. > To fix we will either have to find a way to stop systemd erasing the > /run/squid directory, or patch the Squid code to create the PID file > path as-needed not just the file itself. > For the latter, PRs are welcome upstream. I do not currently have time > to work on this myself - thus the bug report. As I explained above, I don't think using Runtimedirectorypreserve=Yes on the unit file will really fix the bug. I think the best option is to patch squid to create the directory tree by itself, if needed. I'll see about submitting a patch. 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
