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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

(file-get "/proc/sys/net/core/somaxconn")

128

(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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <20240407173313.54ea08fab5b020b97755f38c@speakeasy.net>,
James K. Lowden <jklowden@speakeasy.net> wrote:

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.

That is so cool! Thanks for posting!

--
I shot a man on Fifth Aveneue, just to see him die.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 08 Apr 2024 19:46:32 +0000, James K. Lowden wrote:

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 8 Apr 2024 22:27:24 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Mon, 08 Apr 2024 19:46:32 +0000, James K. Lowden wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)