Is there somewhere I can read about what type of sandboxing Pants employs when it runs processes? I’m attempting to add

--debug

support for our test target (working on a dotnet plugin), and for whatever reason I’m unable to successfully attach to the process from my IDEs. Its unclear to me if this is being caused by the sandboxing or not

It is a very light sandbox. Empty environment (mostly, depending on goal etc), temporary directory. No sysroot/jail/uid shenanigans.

I haven’t written run support yet, guess I could try that next. One observation I had was that the debugger still fails to attach even when I use

run_in_workspace=True

which I found interesting

return TestDebugRequest(InteractiveProcess(
        argv=argv,
        env=env,
        run_in_workspace=True,
        forward_signals_to_process=True,
        restartable=True,
    ))

I think we call it

chroot

in process code, but I've never observed it to behave like an actual chroot.

I’m running OSX fwiw. Theres essentially a loop like

while (!Debugger.IsAttached)
{
    Thread.Sleep(1000);
}

inside the code that waits for the debugger to attach to the process. I don’t know enough about the mechanics of the dotnet internals yet to understand how this is implemented. I believe its similar (network based) but haven’t confirmed yet

Ack! It seems unlikely Pants would get in the way of that. A good way of debugging is using

pants --keep-sandboxes=always

and then manually running the binary outside of Pants. If you can debug then, you've got a good case for it something related to how the binary is launched with Pants. There should be a

__run.sh

script in the sandbox that gives a fairly accurate mimicry of how Pants executes the process.

because this is a plugin, is there still a __run.sh?

Yes, almost always -- if I recall from how test runs work you return a process from the "test rule" that Pants then runs with all other test processes. So it takes the same path as everything else.

from what I’m seeing in the process tree I don’t believe there’s a shell involved here. The dotnet binary is found using

BinaryPathRequest

and its running it like

await Get(FallibleProcessResult, Process, process)

(debug is slightly different because it uses InteractiveProcess, but its the same idea)

Oh, yeah. The __run.sh is put there post-fact, not as the actual runner. It's meant as a debugging tool to emulate what Pants does.

oh interesting. I’ll check that out. Gotta run for now but I appreciate all the help 🙏

No worries, and best of luck 🙂

__run.sh

was a good lead, was able to easily reproduce outside of pants. For whatever reason its the env var

TMPDIR

🤷 I guess the debugger needs it to write temporary files or something