Uh oh!
There was an error while loading. Please reload this page.
Add support for using terminals with Containers and Executables - #173
Conversation
Uh oh!
There was an error while loading. Please reload this page.
| // Socket file lifecycle is owned by the caller, not by ConnManager. Without | ||
| // this opt-out, net.UnixListener.Close() would unlink the path because Go | ||
| // created it via ListenUnix. | ||
| listener.SetUnlinkOnClose(false) |
There was a problem hiding this comment.
The contract here puts UDS socket cleanup on the caller (SetUnlinkOnClose(false) + the comment block above), but no production caller actually unlinks the file. I grepped — os.Remove on the UDS path only happens in test helpers. Concretely, neither controllers/running_container_data.go closeTerminalResources nor internal/exerunners/process_executable_runner.go closeProcessRunResources/waitForConnManagerShutdown calls os.Remove(terminalSpec.UDSPath).
The consequences are user-visible: delete a terminal Executable/Container and recreate it with the same UDSPath and NewConnManager will fail with bind: address already in use → the resource goes to FailedToStart. The file also persists after DCP exits cleanly.
The natural place to fix this is in the cleanup paths after connMgr.Done() resolves — that's also why the executable runner's waitForConnManagerShutdown exists. (The container path doesn't even wait on Done() today; see the field comment on runningContainerData.connMgr which already claims it does.)
There was a problem hiding this comment.
I am going to update that comment on the runningContainerData.connMgr member. But other than that, I am not sure what is the problem here. The contract is, DCP does not create the socket file, the client does, and that means DCP does not delete the socket file either.
And no, If a Container is deleted, and a new Container is created afterwards that uses the same socket path, the socket will be reused, there is no "address in use" problem becasue part of the old Container cleanup is closing the server connection to the socket.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
David Negstad (danegsta)
commented
May 28, 2026
Conceptually, should we consider making the new pty controller be invoked via a child command rather than in the controller process directly? That'd be necessary to set us up for future support of persistent resources. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
a3e5472 to
d8e0892CompareThere was a problem hiding this comment.
So the surprise change I springed on you around having DCP connect to the Terminal Host. I feel like I need to explain why that is necessary (and why we might not want a HMP1 listener in DCP at all).
One of the issues that we'll run into with terminal emulation is timing. Programs can send queries to the terminal emulator to determine settings like mouse support and other terminal capabilities. Sometimes these queries are time sensitive (if you don't get a response in N microseconds fallback to some undesirable compat mode). So to help mitigate that it makes more sense for DCP to first open the connection to the terminal host and make sure that the pathway is cleared before launching the process under DCP.
There was a problem hiding this comment.
Roger. Currently the order of execution is, first start a process connected to a pseudoterminal, then make HMP1 connection to terminal host. I think it should be possible to do a focused change and introduce a new mode where this order is inverted. This should minimize the delay of the terminal host responding to program inquiries. Investigating...
There was a problem hiding this comment.
On related note, I am going to add another mode that has DCP own the terminal socket. David and I don't think the Aspire app host owning the socket will work for persistent Executables and Containers.
There was a problem hiding this comment.
Thinking about it some more, I think I will just change the existing "listen" mode to have DCP own the socket file. So "listen" owns the socket file, and "connect" does not. But that will be a separate PR.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: David Negstad <50252651+danegsta@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.
/backport to release/0.25 |
Started backporting to release/0.25: https://github.com/microsoft/dcp/actions/runs/27224217847 |
Karol Zadora-Przylecki (@karolz-ms) backport PR couldn't be created automatically, please create the backport PR manually! |
Sorry for the size... 😬