2 ms·
Yeah, for this particular issue I don't think there's anything holding them back except the lack of demand. Especially OpenBSD, which isn't very deferential to
by wahern 7y ago
Yeah, for this particular issue I don't think there's anything holding them back except the lack of demand. Especially OpenBSD, which isn't very deferential to ABI compatibility.
Even on Linux opening tens of thousands or hundreds of thousands of file descriptors is exceptionally rare. For example, a couple of weeks ago I helped someone diagnose an issue with Vault which was hitting the soft descriptor resource limit. Vault apparently had no support for increasing this limit internally, neither implicitly nor explicitly (e.g. config or command-line).
When I write massively concurrent applications I always increase this to the hard limit on startup (and maybe increase the hard limit if started as root, especially for a commercial product) because it's such an obvious problem which I've encountered frequently, and no support engineer or sysadmin should to be woken up at 2AM, nor users thwarted for hours or days, because of such a stupid issue, no matter that the solution is trivial (e.g. setting LimitNOFILE in the systemd unit file). So what this tells me is that despite being written in an easily scalable network programming language environment (i.e. Go), few Vault installations actually see several thousands of concurrent connections, including at Vault itself. It's a QoI issue, so if it was common I couldn't fathom an engineer not increasing the soft limit if not the hard limit on startup; and if the engineer balked out of some misplaced principle[1], surely the project or product manager would overrule them.
[1] They might argue that good security practice demands obeying the inherited soft limit. But 1) almost no deployer will think about the limit, let alone the soft limit; 2) even assuming a knowledgable sysadmin, it's still not a very good excuse for not increasing it to the hard limit; and 3) a low limit makes it trivial to accidentally DoS a service.