question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:1
  • Comments:7 (7 by maintainers)

github_iconTop GitHub Comments

2reactions
peterhuenecommented, Feb 8, 2019

@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 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!

0reactions
janvorlicommented, Nov 16, 2017

@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).

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found