You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently it seems only dotnet-trace and dotnet-counters support the --diagnostic-port parameter. Documentation incorrectly states that diagnostic port is supported as a parameter to dotnet-dump.
This limits tooling to scenarios with shared process namespace and requires us to configure a separate listener such as dotnet-monitor. It would be useful to be able to use diagnostic tooling in scenarios with only shared diagnostic port socket (e.g. shared emptyDir between containers).
@hoyosjs yes, I would like to mount tmp and connect to the default diagnostic port from outside the target process namespace. #3877 is exactly what I am looking for in dotnet-dump. In addition it would also be great to have the same support in dotnet-gcdump and dotnet-stack 🤞
Background and Motivation
Currently it seems only dotnet-trace and dotnet-counters support the
--diagnostic-port
parameter. Documentation incorrectly states that diagnostic port is supported as a parameter todotnet-dump
.This limits tooling to scenarios with shared process namespace and requires us to configure a separate listener such as
dotnet-monitor
. It would be useful to be able to use diagnostic tooling in scenarios with only shared diagnostic port socket (e.g. shared emptyDir between containers).Since we can now connect to diagnostic ports using DiagnosticClient is there a reason this capability is not available in all tooling such as
dotnet-dump
?Proposed Feature
Add
--diagnostic-port
support to tooling where it is supported by DiagnosticClient.Usage Examples
dotnet-dump collect --diagnostic-port /tmp/dotnet-diagnostic-1-23456-socket,connect
The text was updated successfully, but these errors were encountered: