Hi Chris, Christopher Baines <m...@cbaines.net> skribis:
> I've now tried running the tests using Guix immediately prior to the > recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf), > and immediately after the merge > (cf3d1763ede1a329c2bc932c84591ab594bb6c96) and the tests passed before, > and failed afterwards. > > I've also tried running the tests manually, I did see a couple of times > a failure that mentioned about "Too many open files" [1]. > > I then attempted to raise the limit for open files, I think using > prlimit like `prlimit --nofile=8096:8096 --pid GUIX_DAEMON_PID` did the > trick, and that meant that I built the package sucessfully. > > I'm thinking now that there's a relationship between the number of cores > the tests are run with, and the required file descriptors. Also, I'm > pretty sure this behaviour changed when core-updates was merged. Indeed, Fibers uses ‘epoll’ and for that it consumes file descriptors proportionally to the number of threads, IIRC. You’d still have to have a large number of threads to hit the default rlimit, but that’s not impossible. > I'll close this bug for now, as I've found a way to build the package. To avoid “random” build failures, perhaps we should include a hack in the ‘check’ phase, like calling ‘setrlimit’ right from there, WDYT? Thanks, Ludo’.
