SIGINT leaves dotnet processes running incorrectly. Causes problems on subsequent builds/runs.
See original GitHub issueSteps to reproduce
docker run .....
dotnet restore
dotnet run
- Press:
ctrl-c
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
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
kernel/common
Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes a build problem where two crypto ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@colemickens, thanks again for reporting this issue to us.
https://github.com/dotnet/cli/pull/10720 has recently been merged which should make the SIGINT handling for all
dotnet
SDK commands consistent. This includesdotnet run
where we were previously not handling the signal, resulting in the parentdotnet
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 willdotnet run
. This is how all thedotnet
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!
@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).