On Linux, SOMAXCONN (the maximum size of the listen queue for a socket) is
not a static constant, but is a configurable kernel parameter. Here is a
simple Python command to return the value for your currently-running
kernel:

print(int(open("/proc/sys/net/core/somaxconn", "rt").read().strip()))

On Mon, 12 Feb 2024 01:54:52 +0000, Lawrence D'Oliveiro wrote:

> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket) is
> not a static constant, but is a configurable kernel parameter. Here is a
> simple Python command to return the value for your currently-running
> kernel:
>
> print(int(open("/proc/sys/net/core/somaxconn", "rt").read().strip()))

Here's the (ba)sh equivalent command:

cat /proc/sys/net/core/somaxconn

--
Lew Pitcher
"In Skills We Trust"

In article <uqd7oa$1hn3i$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>On Mon, 12 Feb 2024 01:54:52 +0000, Lawrence D'Oliveiro wrote:
>
>> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket) is
>> not a static constant, but is a configurable kernel parameter. Here is a
>> simple Python command to return the value for your currently-running
>> kernel:
>>
>> print(int(open("/proc/sys/net/core/somaxconn", "rt").read().strip()))
>
>Here's the (ba)sh equivalent command:
>
> cat /proc/sys/net/core/somaxconn

I expect someone will post the COBOL version any minute now.

--
Those on the right constantly remind us that America is not a
democracy; now they claim that Obama is a threat to democracy.

Lawrence D'Oliveiro , dans le message <uqbtpc$170j7$1@dont-email.me>, a
écrit :
> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket) is
> not a static constant, but is a configurable kernel parameter. Here is a
> simple Python command to return the value for your currently-running
> kernel:
>
> print(int(open("/proc/sys/net/core/somaxconn", "rt").read().strip()))

Why do you think you need it in a program?

On 12 Feb 2024 16:38:32 GMT, Nicolas George wrote:

> Why do you think you need it in a program?

That is normally where SOMAXCONN is needed.

On Mon, 12 Feb 2024 13:51:06 -0000 (UTC), Lew Pitcher wrote:

> On Mon, 12 Feb 2024 01:54:52 +0000, Lawrence D'Oliveiro wrote:
>
>> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket)
>> is not a static constant, but is a configurable kernel parameter. Here
>> is a simple Python command to return the value for your
>> currently-running kernel:
>>
>> print(int(open("/proc/sys/net/core/somaxconn",
>> "rt").read().strip()))
>
> Here's the (ba)sh equivalent command:
>
> cat /proc/sys/net/core/somaxconn

Code normally needs it as an integer.

On Mon, 12 Feb 2024 20:46:04 +0000, Lawrence D'Oliveiro wrote:

> On Mon, 12 Feb 2024 13:51:06 -0000 (UTC), Lew Pitcher wrote:
>
>> On Mon, 12 Feb 2024 01:54:52 +0000, Lawrence D'Oliveiro wrote:
>>
>>> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket)
>>> is not a static constant, but is a configurable kernel parameter. Here
>>> is a simple Python command to return the value for your
>>> currently-running kernel:
>>>
>>> print(int(open("/proc/sys/net/core/somaxconn",
>>> "rt").read().strip()))
>>
>> Here's the (ba)sh equivalent command:
>>
>> cat /proc/sys/net/core/somaxconn
>
> Code normally needs it as an integer.

If you say so...

$(($(cat /proc/sys/net/core/somaxconn) + 1))

I added 1 to somaxconn. It's math, so I must have an integer.

--
Lew Pitcher
"In Skills We Trust"

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Mon, 12 Feb 2024 13:51:06 -0000 (UTC), Lew Pitcher wrote:
>
>> On Mon, 12 Feb 2024 01:54:52 +0000, Lawrence D'Oliveiro wrote:
>>
>>> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket)
>>> is not a static constant, but is a configurable kernel parameter. Here
>>> is a simple Python command to return the value for your
>>> currently-running kernel:
>>>
>>> print(int(open("/proc/sys/net/core/somaxconn",
>>> "rt").read().strip()))
>>
>> Here's the (ba)sh equivalent command:
>>
>> cat /proc/sys/net/core/somaxconn
>
>Code normally needs it as an integer.

$ application -m $(cat /proc/sys/net/core/somaxconn)

On Mon, 12 Feb 2024 15:20:32 -0000 (UTC), Kenny McCormack wrote:

> I expect someone will post the COBOL version any minute now.

.... on BSD.

On Mon, 12 Feb 2024 20:58:53 -0000 (UTC), Lew Pitcher wrote:

> On Mon, 12 Feb 2024 20:46:04 +0000, Lawrence D'Oliveiro wrote:
>
>> Code normally needs it as an integer.
>
> If you say so...
>
> $(($(cat /proc/sys/net/core/somaxconn) + 1))
>
> I added 1 to somaxconn. It's math, so I must have an integer.

Now use it as one.

On Mon, 12 Feb 2024 20:58:53 +0000, Lew Pitcher wrote:

> On Mon, 12 Feb 2024 20:46:04 +0000, Lawrence D'Oliveiro wrote:
>
>> On Mon, 12 Feb 2024 13:51:06 -0000 (UTC), Lew Pitcher wrote:
>>
>>> On Mon, 12 Feb 2024 01:54:52 +0000, Lawrence D'Oliveiro wrote:
>>>
>>>> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket)
>>>> is not a static constant, but is a configurable kernel parameter. Here
>>>> is a simple Python command to return the value for your
>>>> currently-running kernel:
>>>>
>>>> print(int(open("/proc/sys/net/core/somaxconn",
>>>> "rt").read().strip()))
>>>
>>> Here's the (ba)sh equivalent command:
>>>
>>> cat /proc/sys/net/core/somaxconn
>>
>> Code normally needs it as an integer.
>
> If you say so...
>
> $(($(cat /proc/sys/net/core/somaxconn) + 1))
>
> I added 1 to somaxconn. It's math, so I must have an integer.

Here's the thing. Without context, neither Lawrence's solution
nor mine are worth anything.

We note that, in Linux, SOMAXCONN is variable, and we can read
a string equivalent of it's value from file /proc/sys/net/core/somaxconn

Someone posts a "simple python command" to do so, and someone else posts
a bash/sh command to do the same.

But, the OP's unstated context was that the integer value of SOMAXCONN
might be needed in a program /as an integer value/ (and not a string).
The posted code was seemingly intended to show an example of a program
that derived the integer value of SOMAXCONN from the string stored in
the /proc/sys/net/core/somaxconn file.

And the counter-example showed the same thing.

But, in the end, neither example is relevant. For example, neither
example code fragment will be of use in a C (or COBOL) program.

And, so ends my facetious banter about SOMAXCONN. You may now
resume your regularly scheduled programming.
--
Lew Pitcher
"In Skills We Trust"

On Mon, 12 Feb 2024 21:08:26 +0000, Lawrence D'Oliveiro wrote:

> On Mon, 12 Feb 2024 20:58:53 -0000 (UTC), Lew Pitcher wrote:
>
>> On Mon, 12 Feb 2024 20:46:04 +0000, Lawrence D'Oliveiro wrote:
>>
>>> Code normally needs it as an integer.
>>
>> If you say so...
>>
>> $(($(cat /proc/sys/net/core/somaxconn) + 1))
>>
>> I added 1 to somaxconn. It's math, so I must have an integer.
>
> Now use it as one.

OK
echo SOMAXCONN plus 1 equals $(($(cat /proc/sys/net/core/somaxconn) + 1))

--
Lew Pitcher
"In Skills We Trust"

On Mon, 12 Feb 2024 21:09:31 -0000 (UTC), Lew Pitcher wrote:

> On Mon, 12 Feb 2024 21:08:26 +0000, Lawrence D'Oliveiro wrote:
>
>> On Mon, 12 Feb 2024 20:58:53 -0000 (UTC), Lew Pitcher wrote:
>>
>>> On Mon, 12 Feb 2024 20:46:04 +0000, Lawrence D'Oliveiro wrote:
>>>
>>>> Code normally needs it as an integer.
>>>
>>> If you say so...
>>>
>>> $(($(cat /proc/sys/net/core/somaxconn) + 1))
>>>
>>> I added 1 to somaxconn. It's math, so I must have an integer.
>>
>> Now use it as one.
>
> OK
> echo SOMAXCONN plus 1 equals $(($(cat /proc/sys/net/core/somaxconn) +
> 1))

As in:

SOMAXCONN = None # to begin with

def get_SOMAXCONN() :
"returns the Linux kernel-configured value of SOMAXCONN."
global SOMAXCONN
if SOMAXCONN == None :
SOMAXCONN = int(open("/proc/sys/net/core/somaxconn", "rt").read().strip())
#end if
return \
SOMAXCONN
#end get_SOMAXCONN

sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.listen(get_SOMAXCONN())

scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> $ application -m $(cat /proc/sys/net/core/somaxconn)

$ application -m $(</proc/sys/net/core/somaxconn)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-02-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 12 Feb 2024 13:51:06 -0000 (UTC), Lew Pitcher wrote:
>
>> On Mon, 12 Feb 2024 01:54:52 +0000, Lawrence D'Oliveiro wrote:
>>
>>> On Linux, SOMAXCONN (the maximum size of the listen queue for a socket)
>>> is not a static constant, but is a configurable kernel parameter. Here
>>> is a simple Python command to return the value for your
>>> currently-running kernel:
>>>
>>> print(int(open("/proc/sys/net/core/somaxconn",
>>> "rt").read().strip()))
>>
>> Here's the (ba)sh equivalent command:
>>
>> cat /proc/sys/net/core/somaxconn
>
> Code normally needs it as an integer.

This is the TXR Lisp interactive listener of TXR 293.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
TXR is light and portable; take it camping, or to the Bahamas.
1> (file-get "/proc/sys/net/core/somaxconn")
128
2> (typeof (file-get "/proc/sys/net/core/somaxconn"))
fixnum

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Mon, 12 Feb 2024 13:51:30 -0800, Keith Thompson wrote:

> scott@slp53.sl.home (Scott Lurndal) writes: [...]
>
>> $ application -m $(cat /proc/sys/net/core/somaxconn)
>
> $ application -m $(</proc/sys/net/core/somaxconn)

Hah! Somebody found a UUOC!

Lawrence D'Oliveiro , dans le message <uqe01h$1mqnb$3@dont-email.me>, a
écrit :
>> Why do you think you need it in a program?
> That is normally where SOMAXCONN is needed.

Then you should not have trouble giving a specific answer:

Why do you think you need it in a program?

On 12 Feb 2024 22:12:09 GMT, Nicolas George wrote:

> Why do you think you need it in a program?

I posted some example code elsewhere.

Some documentation suggests that calling listen(2) with a negative backlog
is equivalent to setting it to the maximum possible value. But this is not
documented in any place I’m aware of (e.g.
<manpages.debian.org/2/listen.en.html>).

That page does not mention EINVAL as a possible return status, so perhaps
such out-of-range values are acceptable and will be interpreted reasonably
after all?

If this is true, then there is no need to bother determining the explicit
value of SOMAXCONN.

Lawrence D'Oliveiro , dans le message <uqf6rk$20b7p$1@dont-email.me>, a
écrit :
> If this is true, then there is no need to bother determining the explicit
> value of SOMAXCONN.

There is no need to determine the value of SOMAXCONN in a program. Read the
man page more carefully, the solution is in it.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>Some documentation suggests that calling listen(2) with a negative backlog
>is equivalent to setting it to the maximum possible value. But this is not
>documented in any place I’m aware of (e.g.
><manpages.debian.org/2/listen.en.html>).
>
>That page does not mention EINVAL as a possible return status, so perhaps
>such out-of-range values are acceptable and will be interpreted reasonably
>after all?
>
>If this is true, then there is no need to bother determining the explicit
>value of SOMAXCONN.

POSIX says:

"The backlog argument provides a hint to the implementation
which the implementation shall use to limit the number of
outstanding connections in the socket's listen queue. Implementations
may impose a limit on backlog and silently reduce the specified value.
Normally, a larger backlog argument value shall result in a larger
or equal length of the listen queue. Implementations shall support
values of backlog up to SOMAXCONN, defined in <sys/socket.h>."

There's no need to determine the explicit value of SOMAXCONN (128 on
my fedora core installation sys/socket.h). There's no requirement
for the implementation to honor the backlog argument, it's just
a hint.

On Tue, 13 Feb 2024 15:12:30 +0000, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>Some documentation suggests that calling listen(2) with a negative backlog
>>is equivalent to setting it to the maximum possible value. But this is not
>>documented in any place I’m aware of (e.g.
>><manpages.debian.org/2/listen.en.html>).
>>
>>That page does not mention EINVAL as a possible return status, so perhaps
>>such out-of-range values are acceptable and will be interpreted reasonably
>>after all?
>>
>>If this is true, then there is no need to bother determining the explicit
>>value of SOMAXCONN.
>
> POSIX says:
>
> "The backlog argument provides a hint to the implementation
> which the implementation shall use to limit the number of
> outstanding connections in the socket's listen queue. Implementations
> may impose a limit on backlog and silently reduce the specified value.
> Normally, a larger backlog argument value shall result in a larger
> or equal length of the listen queue. Implementations shall support
> values of backlog up to SOMAXCONN, defined in <sys/socket.h>."
>
>
> There's no need to determine the explicit value of SOMAXCONN (128 on
> my fedora core installation sys/socket.h). There's no requirement
> for the implementation to honor the backlog argument, it's just
> a hint.

The Linux Programmer's Manual listen(2) manpage says

"If the backlog argument is greater than the value in
/proc/sys/net/core/somaxconn, then it is silently truncated to that value;
the default value in this file is 128. In kernels before 2.4.25, this limit
was a hard coded value, SOMAXCONN, with the value 128."

Yes, the backlog argument is a /hint/, but (apparently) a hint that the
linux kernel takes seriously. And, Lawrence is correct in both his statements
and his implications:
a) in Linux, /proc/sys/net/core/somaxconn authoritatively represents the value
of the maximum number of backlogged connections, while the value of SOMAXCONN
in <sys/socket.h> does not (although SOMAXCONN represents the /default/
value of /proc/sys/net/core/somaxconn)

b) in Linux, /proc/sys/net/core/somaxconn can be increased or decreased dynamically,
meaning that SOMAXCONN does not represent the "current" state of the maximum
number of backlogged connections.

c) to be accurate, a linux program should retrieve the backlog maximum by reading
/proc/sys/net/core/somaxconn, rather than depending on the value of SOMAXCONN
from <sys/socket.h>

d) (My observation) a linux program cannot accurately determine the backlog maximum,
as it might change (either up or down) /after/ the program reads /proc/sys/net/core/somaxconn
In this case, the programmer could just accede to POSIX, and obtain the default
value from <sys/socket.h>, unless the true current maximum is required.

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher , dans le message <uqg279$23ni8$8@dont-email.me>, a écrit :
> c) to be accurate, a linux program should retrieve the backlog maximum
> by reading /proc/sys/net/core/somaxconn, rather than depending on the
> value of SOMAXCONN from <sys/socket.h>

Wrong: a Linux program should not care what this value is. This is a setting
for administrators, and even a barely useful one.

On Tue, 13 Feb 2024 15:35:05 -0000 (UTC), Lew Pitcher wrote:

> Yes, the backlog argument is a /hint/, but (apparently) a hint that the
> linux kernel takes seriously.

I’ve been looking at the kernel code, to see if I can understand this a
bit more.

Seems each protocol family has its own implementation of calls like
listen(2). For example, the IPv4 implementation can be found here
<https://elixir.bootlin.com/linux/latest/source/net/ipv4/af_inet.c#L190>,
and the unix-sockets version can be found here
<https://elixir.bootlin.com/linux/latest/source/net/unix/af_unix.c#L726>.

You may notice that neither one does much validation of the “backlog”
argument before storing it into the sk_max_ack_backlog field of the struct
sock structure. Which is defined here
<https://elixir.bootlin.com/linux/latest/source/include/net/sock.h#L494>.
And you will note that the field is unsigned (“u32”), while the argument
value being stored into it is signed (“int”).

On Mon, 12 Feb 2024 15:20:32 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:

> > cat /proc/sys/net/core/somaxconn
>
> I expect someone will post the COBOL version any minute now.

As Polonius said, "Brevity Is the soul of wit".

IDENTIFICATION DIVISION.
PROGRAM-ID. SHOW-SOMAXCONN.
AUTHOR. On behalf of Kenny McCormack.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT SOMAXCONN
ASSIGN TO "/proc/sys/net/core/somaxconn"
ORGANIZATION IS SEQUENTIAL.

DATA DIVISION.
FILE SECTION.
FD SOMAXCONN.
01 DATUM PIC 9(8).

WORKING-STORAGE SECTION.

PROCEDURE DIVISION.
OPEN INPUT SOMAXCONN.
READ DATUM.
DISPLAY "somaxconn is " DATUM.
DIVIDE 1024 into DATUM.
DISPLAY "somaxconn is " DATUM " KB".

$ gcobol -oo read-file.cbl && ./o
somaxconn is 4096
somaxconn is 00000004 KB

gcobol is the ISO COBOL front-end being developed for GCC. The
development platform is Ubuntu, but it has been shown to compile under
Open BSD, too, modulo a few patches.

--jkl