Number filedescriptors allowed too low for squid on Focal

[EOLE team]

On Ubuntu Bionic the maximum number of file descriptors was set to 65535 in system V initscript :

root@eolebase:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.6 LTS"
root@eolebase:~# squidclient mgr:info | grep descriptors
 Maximum number of file descriptors: 65535
 Available number of file descriptors: 65529
 Reserved number of file descriptors: 100
root@eolebase:~# grep 65535 /etc/init.d/squid
ulimit -n 65535
 ulimit -n 65535
root@eolebase:~#

On Ubuntu Focal the maximum number of file descriptors is not modified by the (new) systemd initscript and errors like *WARNING! Your cache is running out of filedescriptors* ends up happening :

root@eolebase:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.3 LTS"
root@eolebase:~# squidclient mgr:info | grep descriptors
stub time| WARNING: BCP 177 violation. Detected non-functional IPv6 loopback.
 Maximum number of file descriptors: 1024
 Available number of file descriptors: 1019
 Reserved number of file descriptors: 100
root@eolebase:~#

It is possible to bypass that by overriding the unit but this adaptation should be in native squid systemd unit because it's a regression regression compared to Bionic :

root@eolebase:~# cat >>/etc/systemd/system/squid.service.d/override.conf <<EOF
[Service]
LimitNOFILE=65535
EOF
root@eolebase:~# systemctl daemon-reload
root@eolebase:~# systemctl restart squid.service
root@eolebase:~# squidclient mgr:info | grep descriptors
stub time| WARNING: BCP 177 violation. Detected non-functional IPv6 loopback.
 Maximum number of file descriptors: 65535
 Available number of file descriptors: 65530
 Reserved number of file descriptors: 100
root@eolebase:~#

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: squid 4.10-1ubuntu1.4
ProcVersionSignature: Ubuntu 5.4.0-85.95-generic 5.4.140
Uname: Linux 5.4.0-85-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
CasperMD5CheckResult: skip
Date: Tue Sep 14 09:43:12 2021
InstallationDate: Installed on 2021-07-07 (68 days ago)
InstallationMedia: EOLE 2.8.1 "Focal Fossa" - Release amd64 (20210707.1)
SourcePackage: squid
UpgradeStatus: No upgrade log present (probably fresh install)

[Christian Ehrhardt  (paelzer)]

Thanks for the bug.

The situation is more complex than that and there is a great summary by Amos on the Debian bug - one fix is in 4.8, others to come later.
One will want to track upstream (and Debians) action on it for the next steps.

The suggestion you added do not seem to be a perfect fix for every situation, but it might serve as a workaround for anyone affected in the meantime.

[Sergio Durigan Junior (sergiodj)]

Thanks for the bug report.

Indeed, I can confirm that this limitation affects squid since Focal (and still exists as of this writing, on Impish).

As you can notice, I found an upstream bug and a Debian bug about the same issue. Incidentally, the upstream maintainer is also the Debian package maintainer, and he seems hesitant to explicitly use LimitNOFILE in the systemd service. I understand why and agree with his rationale; see below.

If we inspect the squid.service unit (on Bionic), here's what we see:

# systemctl show squid.service | grep NOFILE
LimitNOFILE=1048576
LimitNOFILESoft=1024

According to setrlimit(2)'s manpage:

       The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may set only
       its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (under Linux: one with the CAP_SYS_RESOURCE
       capability in the initial user namespace) may make arbitrary changes to either limit value.

So you can edit your squid.conf file and set the max_filedescriptors option to a (much) higher value if you want (1048576 at most), because squid will then be able to dinamically increase the fd limit without problems (unless you have a system-wide DefaultLimitNOFILE setting in place).

Because of all I wrote above, I am closing this bug as Invalid. I agree that there could be better documentation regarding these settings and limitations, but I think that's a different issue.

Feel free to reopen the bug (by setting its status as New) if you disagree with my analysis.

Thank you.

[EOLE team (eole-team)]

Thank you for your answers.

I confirm that using the Squid configuration directive max_filedescriptors gives the same result and avoid overriding the systemd unit.

root@eolebase:~# echo "max_filedescriptors 65535" >> /etc/squid/squid.conf
root@eolebase:~# systemctl restart squid.service
root@eolebase:~# squidclient mgr:info | grep descriptors
stub time| WARNING: BCP 177 violation. Detected non-functional IPv6 loopback.
 Maximum number of file descriptors: 65535
 Available number of file descriptors: 65530
 Reserved number of file descriptors: 100
root@eolebase:~#

We will apply this solution.