On Mo, 13.04.20 09:56, Tom Callaway (tcallawa@xxxxxxxxxx) wrote: > C) Chromium's build process gets...angrier. Still doable, but you have to > do things like set ulimit -n 4096. (Fun fact: the man page section for > ulimit says that for -n, "most systems do not allow this value to be set". > Guess modern Linux isn't most systems.) Hmm what precisely fails? Note that in systemd we took the liberty to bump RLIMIT_NOFILE's hard limit to 512K a while back, which one can effectively understand as "there's no limit on fds anymore" (this was on suggestion of some kernel folks, because fds are these days tracked like memory and hence are accounted like that too and are not as expensive as hey used to be). We would have liked to bump the matching soft limit too (i.e. the one you tweak with ulimit -n), but that's something what we can't do without breaking compability a litte bit too agressively: fds above 1023 are not compatible with select(), and plenty software still uses select() (they really shouldn't, it's a terrible interface), and it's a silent failure. Long story short: If there are programs that are likely to deal with large numbers of fds (like in your case, the linker I presume?) they should probably just bump the soft limit to the hard limit early on in their C code, and thus just get as many fds they want. Raising the soft limit up to the hard limit is an unprivileged operation and can be done by regular users. Programs that do that should reset the soft limit back to 1K before forking off foreign programs again though, again for compatibility with any such programs that use select(). Very short version: consider filing a bug against your linker tool (or whichever other tool needed the ulimit -n above), and ask them to set RLIMIT_NOFILE's soft value to the hard value. And then they will just work without any manual limit bumping for regular people on modern distros. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
