Skip to content
This repository has been archived by the owner. It is now read-only.

Ctrl+C doesn't kill the dotnet.exe process when running an ASP.NET Core app interactively in docker #960

Closed
danroth27 opened this issue Mar 10, 2017 · 22 comments

Comments

@danroth27
Copy link
Member

commented Mar 10, 2017

Install Docker

docker run -p 8000:80 -e "ASPNETCORE_URLS=http://+:80" -it --rm microsoft/dotnet
mkdir test
cd test
dotnet new mvc
dotnet restore
dotnet run
Ctrl+C

Output:

Hosting environment: Production
Content root path: /testweb
Now listening on: http://+:80
Application started. Press Ctrl+C to shut down.
^CApplication is shutting down...
 
root@27261394f459:/testweb# ps
   PID TTY          TIME CMD
     1 ?        00:00:00 bash
   119 ?        00:00:03 dotnet
   147 ?        00:00:00 ps 

If you then touch a file and try to dotnet build you will get errors that the app dll is locked by the dotnet.exe process.

@MichaelSimons

This comment has been minimized.

Copy link

commented Mar 14, 2017

As an alternative workaround to manually killing the dotnet process, you can run using the dotnet host instead of dotnet run - e.g. dotnet myApp.dll.

@muratg muratg added this to the 2.0.0 milestone Mar 20, 2017

@muratg

This comment has been minimized.

Copy link

commented Mar 20, 2017

@davidfowl This is possibly related to msbuild or something else in the stack. @glennc has a repro even with a Console app.

@muratg

This comment has been minimized.

Copy link

commented May 15, 2017

@davidfowl did you get a chance to look into this?

@davidfowl

This comment has been minimized.

Copy link
Member

commented May 16, 2017

No, not yet.

@7100SW

This comment has been minimized.

Copy link

commented May 18, 2017

Workaround: Use Windows Powershell; CTRL-C will stop it.

@muratg muratg modified the milestones: 2.0.0-preview3, 2.0.0-preview2 May 25, 2017

@muratg muratg modified the milestones: 2.0.0-preview3, 2.0.0 Jun 12, 2017

@davidfowl

This comment has been minimized.

Copy link
Member

commented Jun 28, 2017

This probably requires changes to dotnet itself. I'm betting Ctrl + C isn't being forwarded to the child process.

@davidfowl

This comment has been minimized.

Copy link
Member

commented Jun 28, 2017

/cc @eerhardt

@muratg

This comment has been minimized.

Copy link

commented Jun 28, 2017

@davidfowl move to 2.1 for now?

@muratg muratg modified the milestones: 2.1.0, 2.0.0 Jul 5, 2017

@mickaelistria

This comment has been minimized.

Copy link

commented Jul 28, 2017

I can reproduce it with dotnet core 2.0 preview on Fedora 26. This causes issue when trying to interact with the IDE (Eclipse IDE) as stopping the process created by the IDE doesn't stop the ASP.NET process. The result is that the user cannot easily control the process from the IDE, and worse, cannot easily run multiple time the project under development without going to console in order to kill the forked process.
What's stange also is that the forked process isn't killed when the child is killed. I would expect killing the dotnet run would cascade to killing the dotnet exec /path/to/project.dll

@mickaelistria

This comment has been minimized.

Copy link

commented Jul 28, 2017

This probably requires changes to dotnet itself. I'm betting Ctrl + C isn't being forwarded to the child process.

@davidfowl Are you aware of a report about it on the dotnet side? I have the same impression that Ctrl+C isn't forwarded and/or that the chain of processes isn't correct.

@muratg

This comment has been minimized.

Copy link

commented Aug 8, 2017

dotnet doesn't forward Ctrl-C to child processes, so we won't be able to fix this in Hosting itself. Closing per the triage team's decision.

@muratg muratg closed this Aug 8, 2017

@mickaelistria

This comment has been minimized.

Copy link

commented Aug 8, 2017

So shouldn't this issue be opened against dotnet directly? Is there an existing one we can already follow?

@mickaelistria

This comment has been minimized.

Copy link

commented Aug 10, 2017

I'm curious: do you know whether most IDEs handle ASP.NET app properly then? How can the IDE user/C# developer doing ASP.NET app perform a run-modify-retry cycle if there is no way to stop the application under development from the host IDE/dotnet instance?

@davidfowl

This comment has been minimized.

Copy link
Member

commented Aug 10, 2017

So shouldn't this issue be opened against dotnet directly? Is there an existing one we can already follow?

Yes, it should be.

I'm curious: do you know whether most IDEs handle ASP.NET app properly then? How can the IDE user/C# developer doing ASP.NET app perform a run-modify-retry cycle if there is no way to stop the application under development from the host IDE/dotnet instance?

None of the IDE's use dotnet run, they directly invoke the binary in the output folder via dotnet app.dll

@mickaelistria

This comment has been minimized.

Copy link

commented Aug 10, 2017

@mickaelistria

This comment has been minimized.

Copy link

commented Aug 12, 2017

I've opened dotnet/cli#7426

@davidfowl

This comment has been minimized.

Copy link
Member

commented Aug 12, 2017

FYI, we're working on the integration of dotnet (core) in Eclipse IDE

Very cool! You should definitely directly run the process.

@mickaelistria

This comment has been minimized.

Copy link

commented Aug 13, 2017

@davidfowl

This comment has been minimized.

Copy link
Member

commented Aug 13, 2017

I don't see how it's best, like I said, none of the existing IDEs do it. For example, how would you get the existing pid to attach the debugger? Just another example of why running the process directly is better from an IDE.

Anyways good luck.

@Kizmar

This comment has been minimized.

Copy link

commented Nov 15, 2017

FWIW: I'm seeing this when using the Integrated Terminal in vscode too.

@muratg muratg modified the milestones: 2.1.0, 2.1.0-preview1 Dec 11, 2017

@martinbliss

This comment has been minimized.

Copy link

commented Oct 23, 2018

I see this thread is closed, but it's not clear if it moved elsewhere or not. The pain is still very real. Is this a VSCode only defect for the VSCode backlog? Considering VSCode's popularity for debugging .NET Core on MacOS, I'm surprised this hasn't already been fixed.

@muratg

This comment has been minimized.

Copy link

commented Oct 23, 2018

@martinbliss Please read the thread since it was closed for more details.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants
You can’t perform that action at this time.