Ludovic Courtès <ludo@gnu.org> writes:

> Christopher Baines <mail@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?

If that's possible, it sounds like a good idea.