Too many open files from Stdune.rm_rf: read_directory_with_kinds

[Alizter]

Downloading dune-configurator.3.21.0
Error:                             
/home/ali/.cache/dune/db/temp/dune_8fa2ea_artifacts(Stdune.Path.rm_rf: read_directory_with_kinds): Too many open files
-> required by
   _build/_private/default/.pkg/dune-configurator.3.21.0-316666eed24b845c1931f550fcaaa3dd/source
-> required by
   _build/_private/default/.pkg/dune-configurator.3.21.0-316666eed24b845c1931f550fcaaa3dd/target/cookie
-> required by Computing closure for package "uri-sexp"
-> required by library "cohttp" in _build/default/cohttp/src
-> required by library "cohttp-top" in _build/default/cohttp-top/src
Fatal error: exception Sys_error("_build/.db: Too many open files")
Raised at Stdune__Result.ok_exn in file "otherlibs/stdune/src/result.ml", line 26, characters 15-22
Called from Stdune__Exn.protectx in file "otherlibs/stdune/src/exn.ml", line 10, characters 8-11
Re-raised at Stdune__Exn.protectx in file "otherlibs/stdune/src/exn.ml", line 16, characters 4-11
Called from Stdlib.at_exit.new_exit in file "stdlib.ml", line 566, characters 59-63
Called from Stdlib.exit in file "stdlib.ml", line 579, characters 2-15
Called from Dune__exe__Main in file "bin/main.ml", line 114, characters 43-64

This started appearing but I have no been able to reproduce as of yet.

[Alizter]

My original suspicion is #13340 or #13341, but this is not yet a certainty. The only info I have is that I've never seen this error before last weekened when the async digest changes were introduced. Is there anything more useful I can do if I encounter this to understand exactly what happened?

[rgrinberg]

#13441 is not merged, so we can rule that out. I've also seen this error plenty of times before #13340.

[rgrinberg]

Try running your repro with spawn configured to use fork instead of vfork. Are you still able to repro?
Try turning off background sandboxes. Are you still able to repro?

[Alizter]

I'm still running into this, I will try to reproduce more reliably and answer your earlier questions.

[rgrinberg]

Upload your traces next time you run into this. We're now collecting enough info that it might be useful to understand the issue;

[Alizter]

Here is a recent one. I haven't tried reproducing or understanding it yet.

my_log.json

[rgrinberg]

I think we're missing sandbox delete events to understand what is happening. Also, what is your soft/hard limit on file descriptors in the first place?

…

On Wed, Jan 28, 2026, at 6:58 PM, Ali Caglayan wrote: *Alizter* left a comment (ocaml/dune#13379) <#13379 (comment)> Here is a recent one. I haven't tried reproducing or understanding it yet. my_log.json <https://github.com/user-attachments/files/24919466/my_log.json> — Reply to this email directly, view it on GitHub <#13379 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB563T6URWWLWIDZ62FM34JEBGDAVCNFSM6AAAAACSE7CUKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJTGI3DSNBQGQ>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[Alizter]

Mine is set to be:

Limit                     Soft Limit           Hard Limit           Units     
Max open files            1024                 524288               files     

by default I believe.

I can artificially cause this issue to happen by doing ulimit -n 20 for example.

[Alizter]

#13489 may solve the issues reported here. I'll leave it open for another week and close it unless I encounter the issue again.