“Error code 26: Text file busy” :eyes: <https://tr...
# development
h
“Error code 26: Text file busy” 👀 https://travis-ci.com/github/pantsbuild/pants/jobs/366361027#L528 This is on John’s PATH PR, where we add a
./script.sh
file via
CreateDigest
to be able to locate any arbitrary binary on the
PATH
. It looks like “Text file busy” is when multiple processes are trying to modify the same file. I don’t know how that could happen with the engine, where each
Process
is its own tmpdir?
w
um. it can also happen when a file has not been fsynced, but that shouldn’t be the case here.
uhhhh
that’s with remoting, right?
h
Yep
macOS shards were fine
w
so, yikes. that’s not our code then =x
1
that’s RBE maybe not fsync’ing
1
i know we do, because we had a bug like that and fixed it at some point
@hundreds-father-404: workaround might be to roll back* the
./script.sh
aspect and continue to use bash
/bin/bash script.sh
👍 1
with a comment explaining the RBE bug. that isn’t inherent.
a
I’m fairly sure that’s an error from the local process executor, not the remote one
Yep, 99% sure -
Error launching process
appears in the local process executor but not the remote one, and the error format looks a lot like rust
w
mm. it was for mypy actually
h
Ah, yeah that is a local run then. Also note that it worked in a followup run where I did
/bin/bash ./script.sh
instead of using the shebang and running
./script.sh
a
Nonetheless, we had the bug once, and apparently we have it again!
w
so… it looks like that bug has resurfaced then. bummer. it’s possible that it never had to do with the fsync changes, my memory could be faulty.
@average-vr-56795: do you recall whether we ever had an explicit fix for that? iirc, the push to fsync things was because files would go missing, rather than for this issue in particular
a
I’m afraid I don’t remember… @enough-analyst-54434 may
w
no worries: thank you!