Getting SOMAXCONN

[Lawrence D'Oliveiro]

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()))

[Lew Pitcher]

Here's the (ba)sh equivalent command:

cat /proc/sys/net/core/somaxconn



--
Lew Pitcher
"In Skills We Trust"

[Kenny McCormack]

In article <uqd7oa$1hn3i$1...@dont-email.me>,

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.

[Nicolas George]

Lawrence D'Oliveiro , dans le message <uqbtpc$170j7$1...@dont-email.me>, a
écrit :

Why do you think you need it in a program?

[Lawrence D'Oliveiro]

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.

[Lawrence D'Oliveiro]

Code normally needs it as an integer.

[Lew Pitcher]

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.

[Scott Lurndal]

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

[Lawrence D'Oliveiro]

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.

[Lawrence D'Oliveiro]

Now use it as one.

[Lew Pitcher]

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]

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

[Lawrence D'Oliveiro]

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())

[Keith Thompson]

sc...@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.T...@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[Kaz Kylheku]

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: @Kazi...@mstdn.ca

[Lawrence D'Oliveiro]

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

> sc...@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!

[Nicolas George]

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:

[Lawrence D'Oliveiro]

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.

[Lawrence D'Oliveiro]

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.

[Nicolas George]

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.

[Scott Lurndal]

Lawrence D'Oliveiro <l...@nz.invalid> writes:

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.

[Lew Pitcher]

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.

[Nicolas George]

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.

[Lawrence D'Oliveiro]

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”).