Linux diagnostic socket name gets truncated when TMPDIR is too long

[TheAngryByrd]

Description

👋 I've run into an issue where if TMPDIR is set to a long enough file path, the diagnostic port will get truncated and various tools will fail to report why. It will create something like {temp}/dotnet-diagnostic-{pid}-{disambiguation_key}-sock (NOTE: the missing et from the end) and various tools will fail to indicate this problem.

The main factor is Max linux socket file length is 108 characters.

I discovered this with ServiceFabric as it sets the TMPDIR by default and uses it's /mnt/{SomeAppName}/{App}{Version} point which can be too long in many cases.

Reproduction Steps

• Set TMPDIR for a dotnet process in Linux to be long enough to cause truncation (the limit is 108)
• Use any diagnostic tool even with that TMPDIR set and see if fail.

Expected behavior

Some error message indicating the socket has been truncated.

Actual behavior

You will get this error message

Please verify that {IpcRootPath} is writable by the current user. If the target process has environment variable TMPDIR set, please set TMPDIR to the same directory. Please see https://aka.ms/dotnet-diagnostics-port for more information

but it won't be clear why it can't find the socket.

Regression?

No response

Known Workarounds

I did try symlinking the socket to a shorter path like /tmp but nothing could read from it which I assume nothing was able to write to it, since it probably looks for the full path described in diagnostic port.

I did change my ServiceFabric config to use a shorter TMPDIR path but I don't see this as ideal as it was set by default for some reason and I don't want to discover problems down the road with more custom configuration.

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.