Comment 3 for bug 1943536

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.