-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Use -1 instead of SOMAXCONN as default listen backlog #24764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
|
Please also update dbus-socket.c and socket_dump(). |
|
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" |
|
So, internally in the kernel in 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. |
|
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. |
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.
|
Given this one stalled I prepped an updated version in #28018. Let's continue there. |
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.
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.
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)
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)
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.