Background and Motivation

This is for Linux, when using dotnet-trace in PID connect mode, e.g dotnet-trace collect --process-id XXX ....

dotnet-trace attempts to connect to the transport pipe in /tmp of the mount namespace it's currently running in. If the target PID runs in a container (or if dotnet-trace itself runs in a container), then its mount namespace is different than the mount namespace of dotnet-trace, and we'll not find its pipe.

This is raised in #810 and the proposed solution (at least from my skimming) is to mount the /tmp such that it's accessible on the host.

Proposed Feature

Another solution that I'm proposing is to access the /tmp of the container, via /proc/pid/root/tmp, in case the target process runs in a different mount namespace (easily checked by comparing the /proc/pid/ns/mnt file of dotnet-trace to the one of the process).

We're using this "trick" in our gProfiler (see usage here), by changing the TMPDIR variable which is respected by dotnet-trace, and it's proved itself to work, so I figured we could place this logic in upstream and have it fixed for everyone :)

I searched through the code a bit and found PAL_GetTransportName which appears to be the relevant function for this change. It also seems to handle the same concept for MacOS (using GetApplicationContainerFolder). I figure that'd be the place to put the matching Linux support.

If you think this could be a good addition, I'm happy to implement this change.

Usage Examples

Profiling/tracing a process running in a container.