| commit | 6a1ce36be271630f6b97bc415f4961605a562ef0 | |
| author | Eric Wong <[email protected]> | |
| Sat, 22 Mar 2025 02:49:38 +0000 (22 02:49 +0000) | ||
| committer | Eric Wong <[email protected]> | |
| Wed, 2 Apr 2025 21:55:57 +0000 (2 21:55 +0000) | ||
| tree | f3e4662496e5d56f6c8d474a33636a117d309642 | treesnapshot (tar.gz zip) |
| parent | 1aa5ffb58ab5ac4c89540bb5d9b3ba6411ffa7d5 | commitdiff |
don't set listen(2) backlog on inherited sockets
By using the listen(2) backlog as-is when inheriting (from
systemd or similar), we can give the sysadmin more control on
controlling overload on a per-listener basis. For systemd
users, this means the `Backlog=' parameter in systemd.socket(5)
can be respected and configured to give certain sockets a
smaller backlog (perhaps combined with with per-listener
`multi-accept' parameter on sockets with the standard (huge)
backlog).
For sockets we create, just use a giant number and let the
kernel clamp it to whatever system-wide limit there is
(e.g. `net.core.somaxconn' sysctl on Linux).
By using the listen(2) backlog as-is when inheriting (from
systemd or similar), we can give the sysadmin more control on
controlling overload on a per-listener basis. For systemd
users, this means the `Backlog=' parameter in systemd.socket(5)
can be respected and configured to give certain sockets a
smaller backlog (perhaps combined with with per-listener
`multi-accept' parameter on sockets with the standard (huge)
backlog).
For sockets we create, just use a giant number and let the
kernel clamp it to whatever system-wide limit there is
(e.g. `net.core.somaxconn' sysctl on Linux).
| lib/yahns/socket_helper.rb | diffblobblamehistory |