| Summary: | dev-dotnet/dotnet-sdk-8.0.105 "No file descriptors available" during build | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ktoupt |
| Component: | Current packages | Assignee: | dotnet project <dotnet> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | ktoupt, xgqt |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
emerge --info |
||
Created attachment 893696 [details]
emerge --info
This is, as you have said, a issue with low ulimit.
The limits I set on my machine:
> sysctl fs.file-max=50000
> ulimit -n 500000
Remember to check the effective "ulimit -a" in the shell you are building the SDK in.
We already have had a simialar report (but could not find the bug, probably was on IRC) from the Gentoo CI. Not ure what is the current ulimit se ton the Gentoo tinderboxes but AFAIK the configs are available on GitHub.
We might add the ulimit check and/or increase to ebuild but IMHO it might be risky or malicious...?
Maybe a check would be sufficient. But we have to test for the minimum first :/
*** This bug has been marked as a duplicate of bug 928938 *** I increased the hard file limit by dropping a file in /etc/security/limits.d: # ulimit -n 1024 # ulimit -Hn 1048576 # cat /etc/security/limits.d/50-nofile.conf * hard nofile 1048576 Afterwards, I was able to build. So I think the hard limit is what needs to be checked (if a check is added to the ebuild)... (In reply to ktoupt from comment #4) > # ulimit -Hn > 1048576 > So I think the hard limit is what needs to be checked (if a check is added to > the ebuild)... ktoupt, thanks a lot for the report! |
Created attachment 893695 [details] build.log [ebuild U ] dev-dotnet/dotnet-sdk-8.0.105 [8.0.102-r1] I didn't have much running in the background other than a couple of system daemons and the emerge running in a tmux with everyone else logged out and on the Linux console screen. So this is probably not the kernel running out of file descriptors but some ulimit?