SIGINT leaves dotnet processes running incorrectly. Causes problems on subsequent builds/runs.

[colemickens]

Steps to reproduce

1. docker run .....
2. dotnet restore
3. dotnet run
4. Press: ctrl-c
5. dotnet run

Expected behavior

Everything works because the relevant dotnet processes were stopped and can simply be started again.

Actual behavior

There are old dotnet processes lying around that I must kill manually:

root@pixel:/polykube-aspnet-api/source/aspnet-api# dotnet run

# ...
REDIS: Connected!
POSTGRES: Connected!
new data context
Hosting environment: Production
Content root path: /polykube-aspnet-api/source/aspnet-api/bin/Debug/netcoreapp1.0
Now listening on: http://0.0.0.0:9080
Application started. Press Ctrl+C to shut down.
^CApplication is shutting down...

root@pixel:/polykube-aspnet-api/source/aspnet-api# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 /bin/bash
  180 ?        TLl    0:02 dotnet exec /polykube-aspnet-api/source/aspnet-api/bin/Debug/netcoreapp1.0/aspnet-api.dll
  201 ?        R+     0:00 ps ax

# edit some file to trigger a recompile

root@pixel:/polykube-aspnet-api/source/aspnet-api# dotnet run

/usr/share/dotnet/sdk/1.0.0-preview3-004056/Microsoft.Common.CurrentVersion.targets(3906,5): warning MSB3026: Could not copy "obj/Debug/netcoreapp1.0/aspnet-api.dll" to "bin/Debug/netcoreapp1.0/aspnet-api.dll". Beginning retry 1 in 1000ms. The process cannot access the file '/polykube-aspnet-api/source/aspnet-api/bin/Debug/netcoreapp1.0/aspnet-api.dll' because it is being used by another process. [/polykube-aspnet-api/source/aspnet-api/aspnet-api.csproj]
/usr/share/dotnet/sdk/1.0.0-preview3-004056/Microsoft.Common.CurrentVersion.targets(3906,5): warning MSB3026: Could not copy "obj/Debug/netcoreapp1.0/aspnet-api.dll" to "bin/Debug/netcoreapp1.0/aspnet-api.dll". Beginning retry 1 in 1000ms. The process cannot access the file '/polykube-aspnet-api/source/aspnet-api/bin/Debug/netcoreapp1.0/aspnet-api.dll' because it is being used by another process. [/polykube-aspnet-api/source/aspnet-api/aspnet-api.csproj]
/usr/share/dotnet/sdk/1.0.0-preview3-004056/Microsoft.Common.CurrentVersion.targets(3906,5): warning MSB3026: Could not copy "obj/Debug/netcoreapp1.0/aspnet-api.dll" to "bin/Debug/netcoreapp1.0/aspnet-api.dll". Beginning retry 1 in 1000ms. The process cannot access the file '/polykube-aspnet-api/source/aspnet-api/bin/Debug/netcoreapp1.0/aspnet-api.dll' because it is being used by another process. [/polykube-aspnet-api/source/aspnet-api/aspnet-api.csproj]
/usr/share/dotnet/sdk/1.0.0-preview3-004056/Microsoft.Common.CurrentVersion.targets(3906,5): warning MSB3026: Could not copy "obj/Debug/netcoreapp1.0/aspnet-api.dll" to "bin/Debug/netcoreapp1.0/aspnet-api.dll". Beginning retry 1 in 1000ms. The process cannot access the file '/polykube-aspnet-api/source/aspnet-api/bin/Debug/netcoreapp1.0/aspnet-api.dll' because it is being used by another process. [/polykube-aspnet-api/source/aspnet-api/aspnet-api.csproj]
# ...
/usr/share/dotnet/sdk/1.0.0-preview3-004056/Microsoft.Common.CurrentVersion.targets(3906,5): error MSB3027: Could not copy "obj/Debug/netcoreapp1.0/aspnet-api.dll" to "bin/Debug/netcoreapp1.0/aspnet-api.dll". Exceeded retry count of 10. Failed. [/polykube-aspnet-api/source/aspnet-api/aspnet-api.csproj]
/usr/share/dotnet/sdk/1.0.0-preview3-004056/Microsoft.Common.CurrentVersion.targets(3906,5): error MSB3021: Unable to copy file "obj/Debug/netcoreapp1.0/aspnet-api.dll" to "bin/Debug/netcoreapp1.0/aspnet-api.dll". The process cannot access the file '/polykube-aspnet-api/source/aspnet-api/bin/Debug/netcoreapp1.0/aspnet-api.dll' because it is being used by another process. [/polykube-aspnet-api/source/aspnet-api/aspnet-api.csproj]

The build failed. Please fix the build errors and run again.

I have to manually kill the processes that stick around.

If I just do dotnet run over and over, without editting files, it's fine, and then I wind up with numerous dotnet exec processes hanging around.

Environment data

dotnet --info output:

Note, I'm running this all in the docker container:

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     debian
 OS Version:  8
 OS Platform: Linux
 RID:         debian.8-x64

[TheRealPiotrP]

This is related to https://github.com/dotnet/corefx/issues/1838. We don't have a great mechanism for passing Ctrl+C to other processes at the moment...

[janvorli]

@piotrpMSFT I was wondering few times before - why do we need to have two processes running for dotnet run (one for dotnet run, the other for its child dotnet exec)? If we didn't have that, we would not have this issue with ctrl-c

[TheRealPiotrP]

@janvorli CLI is designed to run code it doesn't ship out-of-proc wherever it can. This comes down to assembly binding. dotnet run will pull in some dependencies e.g. a coreclr before even considering the app to be run. If those dependencies are different than what the app is built against then run will produce a different behavior than the app to be run would if executed directly.

[TheRealPiotrP]

#4779 is likely related.

[livarcocc]

@janvorli is there anything we can do here on the CLI side? Like @TheRealPiotrP stated, we can't really run the application in the CLI context, as that could lead to dependencies problems.

[janvorli]

@livarcocc I actually wonder why the child dotnet process doesn't receive the SIGINT from the CTRL-C. I've seen a stackoverflow post that was solving the opposite issue - how to make sure the child process does not receive the SIGINT so that the parent can wait for it to complete before it shuts down on the SIGINT (https://stackoverflow.com/questions/6803395/child-process-receives-parents-sigint).
So it seems it should be the default behavior (the parent and child process should share the same process group and so the SIGINT should get delivered to both of them).

[peterhuene]

@colemickens, thanks again for reporting this issue to us.

dotnet/cli#10720 has recently been merged which should make the SIGINT handling for all dotnet SDK commands consistent. This includes dotnet run where we were previously not handling the signal, resulting in the parent dotnet process to abort while the child continued to run while handling the SIGINT (which is ASP.NET's shutdown procedure in this case).

The behavior now is to wait for the child process to terminate before the parent dotnet process terminates. It will also now exit with the same code the child process exited with; so if ASP.NET (or some other handler for SIGINT) considers SIGINT to be a graceful exit and returns 0, so will dotnet run. This is how all the dotnet SDK commands now behave for a consistent experience.

I am closing this issue as I believe it to now be resolved. If you are able to reproduce this on a recent 3.0 SDK build (keep in mind it usually takes a day or two for a fix to show up in the nightly SDK builds due to we flow dependencies between multiple repositories), please reopen this issue!

Thanks!