Skip to content

Conversation

@crrodriguez
Copy link
Contributor

SOMAXCONN is the wrong limit to obey and its value changes according to kernel versions, old versions use 128, newer 4096, this is sometimes still not enough. Just use "-1" ideom that will cap it to the system's default, which is the value of sysctl net.core.somaxconn.

This ensures all systemd components obey the system's
net.core.somaxconn sysctl value and not the legacy hardcoded limit.
assert(u->load_state == UNIT_STUB);

s->backlog = SOMAXCONN;
s->backlog = -1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change the type of Socket.backlog from unsigned to int.

Also, please change the conf parser to config_parse_int(). See src/core/load-fragment-gperf.gperf

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

huh.. yeah thanks . will do.

@yuwata
Copy link
Member

yuwata commented Sep 20, 2022

Please also update dbus-socket.c and socket_dump().

@yuwata yuwata added reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks tree-wide labels Sep 20, 2022
@poettering
Copy link
Member

Hmm, not sure how I feel about this...

The man page says nothing about "-1" being a thing...

wouldn't INT_MAX be a better thing to use? That would be perfectly in-line with the man page?

And generally: is it actually the right thing to do to set the value to the max possible? (not saying it wasn't, but I am looking for strong reason behind this)

@crrodriguez
Copy link
Contributor Author

Hmm, not sure how I feel about this...

The man page says nothing about "-1" being a thing...

wouldn't INT_MAX be a better thing to use? That would be perfectly in-line with the man page?

And generally: is it actually the right thing to do to set the value to the max possible? (not saying it wasn't, but I am looking for strong reason behind this)

at least kernel maintainers say it means "system's default"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19f92a030ca6d772ab44b22ee6a01378a8cb32d4
but Int_MAX should do too..

@poettering
Copy link
Member

So, internally in the kernel in __sys_listen(), the first thing it does, is convert the parameter to an unsigned, which thus will convert -1 to UINT_MAX (at least on two complement systems).

Ther kernel hence appears to be a bit confused about the types here, i.e. something that is official signed is actually used as unsigned value. I am pretty sure we should thus remain conservative and use INT_MAX here, i.e. the largest possible value that the offical type can take.

@poettering
Copy link
Member

So, let's do this. I thought a bit about this and I think it#s one of these artificial limits that we should probably just get rid of. it's primarily just memory this is limited through that, but socket memory is nowadays tracked properly via memcg and so on, so not really necessary to bother. Moreover effectively this just raises things from 128 to 4K which isn't that terrible either.

But, can you rework this to change this to INT_MAX everywhere?

And also add this to NEWS, since this is kinda an incompatible change.

poettering added a commit to poettering/systemd that referenced this pull request Jun 13, 2023
This is a rework of systemd#24764 by Cristian Rodríguez
<crodriguez@owncloud.com>, which stalled.

Instead of assigning -1 we'll use a macro defined to INT_MAX however.
@poettering
Copy link
Member

poettering commented Jun 13, 2023

Given this one stalled I prepped an updated version in #28018. Let's continue there.

@poettering poettering closed this Jun 13, 2023
@github-actions github-actions bot removed the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Jun 13, 2023
poettering added a commit to poettering/systemd that referenced this pull request Jun 13, 2023
This is a rework of systemd#24764 by Cristian Rodríguez
<crodriguez@owncloud.com>, which stalled.

Instead of assigning -1 we'll use a macro defined to INT_MAX however.
poettering added a commit that referenced this pull request Jun 13, 2023
This is a rework of #24764 by Cristian Rodríguez
<crodriguez@owncloud.com>, which stalled.

Instead of assigning -1 we'll use a macro defined to INT_MAX however.
valentindavid pushed a commit to valentindavid/systemd that referenced this pull request Aug 8, 2023
This is a rework of systemd#24764 by Cristian Rodríguez
<crodriguez@owncloud.com>, which stalled.

Instead of assigning -1 we'll use a macro defined to INT_MAX however.

(cherry picked from commit 768fcd7)
(cherry picked from commit fec3350)
(cherry picked from commit f8e8ff5)
yuwata pushed a commit to yuwata/systemd that referenced this pull request Apr 26, 2024
This is a rework of systemd#24764 by Cristian Rodríguez
<crodriguez@owncloud.com>, which stalled.

Instead of assigning -1 we'll use a macro defined to INT_MAX however.

(cherry picked from commit 768fcd7)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

3 participants