Aspire.Hosting.Dashboard - Failed to bind to address, address already in use. #5112
Open
1 task done
Labels
area-app-model
Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication
area-dashboard
untriaged
New issue has not been triaged
Comments
|
Failed to bind to address I'm having something similar issue - running it in administrator mode doesn't resolve it either. |
|
@davidfowl any idea how to resolve this? |
|
Look for an existing running aspire dashboard and kill the process |
davidfowl
added
area-app-model
|
This is incredibly annoying, having to wait up to a minute (sometimes several minutes) everytime I stop the app before I can re-start it. Depending on what I'm working on, this is wasting up to like half an hour per day. Using |
|
Are you seeing this every time you stop aspire? Id so can you record a video of the repro and share it here? If we’re able to get a reliable repro then we might be able to fix the problem (or mitigate). |
|
More-or-less every time, ye. Sometimes it's near-instant though, but that's a minority. It seems like it's happening because of NodeJS. Specifically we're running I'll try it out tomorrow to see if this still happens if I remove the nextjs applications, or if it's unrelated. |
|
Might be related to this #6221 (comment) |
|
The description of that issue sounds a lot like what I'm experiencing too, when it comes to stopping of resources as well. I probably should've mentioned that this is indeed on the .Net 9 preview, and I can't remember whether it was a problem before upgrading to said preview, or if it started with net9, as described in the issue |
|
The issue was likely exacerbated by changes made during 9.0 preview; we weren't always waiting for stdio to flush when shutting down services (which could result in file in use errors when we tried to cleanup the log files for a restarted process). We made a change to ensure we always wait for stdio, but that introduced a regression in the event that the kill signal wasn't forwarded to child processes (which seems to be the case with node.js on Windows). We likely weren't properly cleaning up node processes before the regression, but now it could cause a deadlock during resource cleanup preventing us from completing the full teardown before we finally timed out. For executables we spawn additional cleanup processes whose only role is to kill forked service processes if we don't have a clean exit/complete the normal teardown, which is why we were still cleaning up those resources after everything timed out, but potentially leaving behind containers that weren't cleaned up. Good news is a fix should be in main later today. |
|
Okay, a fix for one potential cause of this issue is in (failure to cleanup some resources cleanly during shutdown) has been merged, but I can't guarantee it will solve all the address in use cases that have been reported, so I'm reluctant to close this particular issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue for this?
Describe the bug
This issue was also mentioned by @mitchdenny from #2198. But I did not see any solutions mentioned specifically for this (unless I read right over it)
However, the first time I run the app and then stop it. Every start up after that causes the following issues:
Changes made to not see this issue again:
launchSettings.jsonfileIf I change the ports back, the issue still remains. I have the latest Aspire nuget packages, WSL 2, Docker Desktop and Visual Studio 2022 Professional. All up to date.
What can I do so that my team does not have to run it once and then immediately change ports to solve this current issue?
Expected Behavior
No response
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version info
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: