Hacker News Reader

Comment by lathiat | Hacker News Reader

This issue has been driving me crazy and I spent a while a couple of times trying to figure out why the limit was 1024 and if we could bump the default. I got sidetracked and never finished it either time. I also separately knew about the select() issue but hadn't linked the two.

This sounds like a great change in that at least software can opt-in without having to even edit their systemd unit.

View on HN

All parent processes above you need to first increase their ulimit. Check the blog link in my other post here for details. Changing the daemon's ulimit in with systemd is actually super easy with one line: LimitNOFILE=<your-limit>

Yep I know about that, but was more specifically interested in the case of not having to make such changes and having it just work (tm). Resource-wise having a 50,000 or 500,000 default ulimit wouldn't matter. But we find out here, it matters for compatability.

But with the systemd change he mentioned (which for Ubuntu, exists in 20.04 but not 18.04) - that the HARD limit is now 512k - applications can chose to adjust the ulimit from inside the application that is not running as root. So all modern software can just, if it knows its OK, make the call during startup to increase the limit to whatever it thinks is needed. Then we dont have to override.conf systemd services every time you hit a scaling limit or think about it.

Reply on news.ycombinator.com