Open Bluezen opened 2 weeks ago
Thanks for creating your first issue; let us know what you think of dotnet-monitor by filling out our survey.
With .NET 8+ dotnet-monitor now runs as non-root in our images. This isn't an issue if both the application being monitored and dotnet-monitor run as the same user but if the users of the two applications mismatches, then we likely won't be able to connect. You can read more about this in our docs here.
When we originally released dotnet-monitor 8 the default ASP.NET sample application also ran as non-root so this wasn't an issue. It appears that this has since changed and the sample application run as root
which means our image won't be able to monitor it.
Solutions (either will work):
mcr.microsoft.com/dotnet/samples:aspnetapp-chiseled
image instead. This runs as the same user as our dotnet-monitor image and should just work.mcr.microsoft.com/dotnet/samples:aspnetapp
image to 1654:1654
(e.g. docker run -it --user 1654:1654 -v diag:/tmp -p 8080:8080 mcr.microsoft.com/dotnet/samples:aspnetapp
)We'll also look at updating our documentation around this.
Description
Hello, Since upgrading to version 8 of dotnet-monitor, we’ve noticed that no processes are being detected when using Connect mode and the default diagnostic port.
To reproduce this issue, start an application that exposes the
/tmp
folder in a volume (here nameddiag
):then start dotnet-monitor with the same (
diag
) volume mounted:When you access
http://localhost:52323/processes
, it returns an empty list[]
. We would expect to see some processes listed instead, like for example:as a dotnet-monitor in versions 6 or 7 behaved.
Regression?
To observe the change in behavior, simply update the version number to 7:
or version 6:
then access
http://localhost:52323/processes
, you should see some processes listed.I’ve reviewed the documentation and couldn’t find any information about changes to configuration or behavior since version 8. Am I overlooking something?