From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject: squid 5.1 gone stable
Date: Sat, 07 Aug 2021 18:13:39 +0200
Message-ID: <90410d8f-9b80-1129-7cd7-3652d2951e1d@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9081707264970777073=="
List-Id: <development.lists.ipfire.org>

--===============9081707264970777073==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

...for the records...: ;-)

Today I tested building 'squid 5.1' with our usual configure options:

...
--with-dl \
--with-filedescriptors=$(( 16384 * 64 )) \
--with-large-files \
--without-gnutls \
...

No errors in '_build.ipfire.log' for this 'squid' - except:

...
checking for library containing log... none required
configure: forcing default of 1048576 filedescriptors (user-forced)
checking Default FD_SETSIZE value... 1024
checking for getrlimit... yes
checking for setrlimit... yes
checking Maximum number of filedescriptors we can open... 32768
configure: Default number of filedescriptors: 1048576
...

So the maximum number of filedescriptors which are possible for 'squid
5.1' are 32768!?

Ok then. I rebuilt the whole thing with the "maximum":

...
--with-filedescriptors=32768 \
...

But no change. During starting, 'squid 5.1.' still complains:
...
NOTICE: Could not increase the number of filedescriptors
With 4096 file descriptors available
...

This is the value reported by 'ulimit -n' on my IPFire / Core 158.

Currently, only 'squid 4.16' can increase this number under *exactly*
the same environment.

What consequences could it have, respectively!?

Best,
Matthias

--===============9081707264970777073==--