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]

Post by 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
print(int(open("/proc/sys/net/core/somaxconn", "rt").read().strip()))

Here's the (ba)sh equivalent command:

cat /proc/sys/net/core/somaxconn

[Kenny McCormack]

Post by Lew Pitcher

Post by 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
print(int(open("/proc/sys/net/core/somaxconn", "rt").read().strip()))

cat /proc/sys/net/core/somaxconn

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

[Lawrence D'Oliveiro]

Post by Kenny McCormack
I expect someone will post the COBOL version any minute now.

... on BSD.

[James K. Lowden]

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

Post by Kenny McCormack

Post by Lew Pitcher
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

[Kenny McCormack]

Post by James K. Lowden
On Mon, 12 Feb 2024 15:20:32 -0000 (UTC)

Post by Kenny McCormack

Post by Lew Pitcher
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.

That is so cool! Thanks for posting!

[Lawrence D'Oliveiro]

DISPLAY "somaxconn is " DATUM. DIVIDE 1024 into DATUM.
DISPLAY "somaxconn is " DATUM " KB".

Just a note that SOMAXCONN is a number of entries (the limit on the
accept-pending queue), not a size in bytes.

gcobol is the ISO COBOL front-end being developed for GCC.

Is that different from gnucobol?

[Keith Thompson]

Post by Lawrence D'Oliveiro

DISPLAY "somaxconn is " DATUM. DIVIDE 1024 into DATUM.
DISPLAY "somaxconn is " DATUM " KB".

Just a note that SOMAXCONN is a number of entries (the limit on the
accept-pending queue), not a size in bytes.

gcobol is the ISO COBOL front-end being developed for GCC.

Is that different from gnucobol?

Yes. GnuCOBOL evolved from OpenCOBOL, and is a translator that
generates C code that's fed to gcc. gcobol (which is newer) is a
frontend for gcc.

[James K. Lowden]

On Mon, 8 Apr 2024 22:27:24 -0000 (UTC)

Post by Lawrence D'Oliveiro

DISPLAY "somaxconn is " DATUM. DIVIDE 1024 into DATUM.
DISPLAY "somaxconn is " DATUM " KB".

Just a note that SOMAXCONN is a number of entries (the limit on the
accept-pending queue), not a size in bytes.

A useful clarification, thanks. I should have known, from the
discussion. Or, you know, documentation. :-)

The intention was only to show that PIC 9(8) in COBOL is a computable
field where the numerical value is held as a sequence of up
to 8 characters.

Post by Lawrence D'Oliveiro

gcobol is the ISO COBOL front-end being developed for GCC.

Is that different from gnucobol?

Yes. GnuCOBOL is another, much older, project. It converts COBOL to
C, and uses a C compiler (usually gcc) to produce executable code.

gcobol extends GCC directly and sits alongside the other languages --
C, C++, Java, Fortran, Go, Modula2, Pascal, Rust, et al. -- that gcc
compiles.

At present, gcobol is maintained in separate repository

https://gitlab.cobolworx.com/COBOLworx/gcc-cobol

that is updated periodically from the main GCC repository. We are in
the process of merging the code upstream, after which point COBOL will
become part of the official GCC distribution.

--jkl

[Lawrence D'Oliveiro]

Post by Lew Pitcher

Post by 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
print(int(open("/proc/sys/net/core/somaxconn",
"rt").read().strip()))

cat /proc/sys/net/core/somaxconn

Code normally needs it as an integer.

[Lew Pitcher]

Post by Lawrence D'Oliveiro

Post by Lew Pitcher

Post by 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
print(int(open("/proc/sys/net/core/somaxconn",
"rt").read().strip()))

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.

[Lawrence D'Oliveiro]

Post by Lew Pitcher

Post by Lawrence D'Oliveiro
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.

[Lew Pitcher]

Post by Lawrence D'Oliveiro

Post by Lew Pitcher

Post by Lawrence D'Oliveiro
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))

[Lawrence D'Oliveiro]

Post by Lew Pitcher

Post by Lawrence D'Oliveiro

Post by Lew Pitcher

Post by Lawrence D'Oliveiro
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())

[Lew Pitcher]

Post by Lew Pitcher

Post by Lawrence D'Oliveiro

Post by Lew Pitcher

Post by 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
print(int(open("/proc/sys/net/core/somaxconn",
"rt").read().strip()))

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.

[Scott Lurndal]

Post by Lawrence D'Oliveiro

Post by Lew Pitcher

Post by 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
print(int(open("/proc/sys/net/core/somaxconn",
"rt").read().strip()))

cat /proc/sys/net/core/somaxconn

Code normally needs it as an integer.

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

[Keith Thompson]

***@slp53.sl.home (Scott Lurndal) writes:
[...]

Post by Scott Lurndal
$ application -m $(cat /proc/sys/net/core/somaxconn)

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

[Lawrence D'Oliveiro]

Post by Keith Thompson

Post by Scott Lurndal
$ application -m $(cat /proc/sys/net/core/somaxconn)

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

Hah! Somebody found a UUOC!

[Kaz Kylheku]

Post by Lawrence D'Oliveiro

Post by Lew Pitcher

Post by 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
print(int(open("/proc/sys/net/core/somaxconn",
"rt").read().strip()))

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

[Nicolas George]

Post by 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
print(int(open("/proc/sys/net/core/somaxconn", "rt").read().strip()))

Why do you think you need it in a program?

[Lawrence D'Oliveiro]

Post by Nicolas George
Why do you think you need it in a program?

That is normally where SOMAXCONN is needed.

[Nicolas George]

Post by Lawrence D'Oliveiro

Post by Nicolas George
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?

[Lawrence D'Oliveiro]

Post by Nicolas George
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]

Post by Lawrence D'Oliveiro
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]

Post by 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.

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]

Post by Scott Lurndal

Post by 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.

"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.

[Nicolas George]

Post by Lew Pitcher
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]

Post by Lew Pitcher
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”).