<{^_^}>
#29087 (by copumpkin, 1 year ago, open): Resurrect Nix Darwin sandbox
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-borg
<infinisil>
ekleog: the pr isn't merged?
<gchristensen>
because the sandbox isn't very thorough
<timokau[m]>
Apparently there have been at least 3 instances of errors in the lines of `runtime: failed to create new OS thread (have n already; errno=11)` on aarch ofborg
<timokau[m]>
Could that be an ofborg limitation/bug or rather a software error?
<ekleog>
timokau[m]: these error messages are from go, run from inside the derivation build, right? if so, I don't really see how it could be a limitation of ofborg, because ofborg basically launches nix-build [right arguments]
<ekleog>
could be a limitation of nix-build on aarch64, maybe ? do you have access/did you try building on the aarch64 community builder? (I don't have access myself, but ISTR there is a community builder)
<ekleog>
(if I'm not mistaken [right arguments] are nix-build --no-out-link --keep-going --show-trace --option restrict-eval true --option build-timeout [timeout] --argstr system [system] [--arg supportedSystems [systems]] [file] -A [req1] … -A [reqN] ; but it's based on a quick reading of https://github.com/NixOS/ofborg/blob/released/ofborg/src/nix.rs and I'm not sure)
<ekleog>
gchristensen: stupid question: what would you think about prepending the nix-build command ofborg ran on the top of the log?
<ekleog>
(might hopefully make debugging of such issues easier)
<timokau[m]>
ekleog: No I don't have access either. At least the build apparently worked on hydra before but someone on one of those issues also mentioned that the issue appears transient, so maybe thats the reason.
<timokau[m]>
ekleog: maybe in the future, for now I don't want to got too far down the rabbit hole in debugging this (since I don't personally care for any of the packages). I'll just try to determine if its a nix/ofborg/package issue.
<ekleog>
'k :) intuitively I'd say it'd hard to be ofborg, so it may be either nix, .nix package (which I didn't read), or .go package
<timokau[m]>
I agree, I only asked here in case it is a known issue since xej (I think) suggested that it may be ofborg in one of those issues. I'd guess its some assumption go makes that is broken by the limited sandbox environment.
<ekleog>
hmm… maybe something like nix restricting the total number of threads and go going over this limit? though EAGAIN (“try again”) error code sounds unlikely for this
<timokau[m]>
Maybe ofborg limits thread count?
<timokau[m]>
`runtime: may need to increase max user processes (ulimit -u)`
<timokau[m]>
By the way, is there a way to get a raw ofborg log (no viewer)?
<samueldr>
it would be a good idea to add a link to the raw log unconditionally
<timokau[m]>
Ah okay at least I can do it manually that way
<timokau[m]>
It starts complaining about new threads when it "has 2 already" so its probably not an issue of the thread limit being too low
<timokau[m]>
Oh forget that, it would be a systemwide limit
<samueldr>
if whatever runs is running in parallel, maybe it's too much all at once if it checks the amount of CPUs available?
<timokau[m]>
Maybe
<timokau[m]>
Theres some cases of the same error online, more or less solutionless. I think I'll just give up now before I spend too much time on it, which I'm guaranteed to do otherwise :D
<gchristensen>
sorry, it is hardfor me to fix this stuff right now