Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet watch run does not forward SIGTERM to child process #20152

Closed
rhyek opened this issue Mar 25, 2020 · 3 comments
Closed

dotnet watch run does not forward SIGTERM to child process #20152

rhyek opened this issue Mar 25, 2020 · 3 comments
Labels
affected-few This issue impacts only small number of customers area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI bug This issue describes a behavior which is not expected - a bug. feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) investigate severity-major This label is used by an internal tool
Milestone

Comments

@rhyek
Copy link

rhyek commented Mar 25, 2020

I am running an Orleans silo inside a local kubernetes cluster (using KinD). This is meant for local development. At the same time, I am using tilt and its "live update" functionality which essentially copies any modified files on my local filesystem to the container running my app. Doing so, I can run my program with dotnet watch run inside the kubernetes-hosted container relying on its file-watching capabilities to avoid unnecessary image rebuilds.

However, rolling updates are necessary at times (testing scaling, for example) and I am having issues with the application not shutting down gracefully due to the fact that dotnet watch run does not forward the SIGTERM sent by kubernetes (unless of course I'm missing something) for pod termination.

This is not directly a Kubernetes-related issue, but I'm providing some context in case it helps anyone in some way. This is my current workaround unless someone has a better idea:

Program.cs

namespace OrleansService.Silo {

  public class Program {
    public static async Task Main(string[] args) {
      var builder = CreateHostBuilder();
      await builder.Build().RunAsync();
    }

    private static IHostBuilder CreateHostBuilder() {
      var builder = Host.CreateDefaultBuilder()
        .ConfigureLogging(logging => logging.AddConsole())
        .UseOrleans(siloBuilder => {
          siloBuilder.Configure<ClusterOptions>(options => {
              options.ClusterId = "main-cluster";
              options.ServiceId = "main-service";
            })
            .UseKubeMembership(opt => {
              opt.CanCreateResources = false;
            })
            .ConfigureEndpoints(new Random(1).Next(30001, 30100), new Random(1).Next(20001, 20100), listenOnAnyHostAddress : true)
            .ConfigureApplicationParts(parts => parts.AddApplicationPart(typeof(TodoGrain).Assembly).WithReferences())
            .ConfigureServices(services => {
              services.AddSingleton<IDbConnectionService, PgConnectionService>();
            });
        });
      return builder;
    }
  }
}

Dockerfile:

FROM mcr.microsoft.com/dotnet/core/sdk:3.1
RUN apt update && apt install python3 python3-pip -y
RUN pip3 install psutil

WORKDIR /src
COPY . .
WORKDIR /src/Silo

CMD exec python3 dev.py

dev.py

import signal
import time
import subprocess
import psutil
import os
import re

child = subprocess.Popen(["dotnet", "watch", "run"])

running = True


def close(a, b):
    global running
    process = psutil.Process(child.pid)
    for proc in process.children(recursive=True):
        path = proc.exe()
        if re.search("/bin/.+netcoreapp", path):
            proc.send_signal(signal.SIGTERM)
            proc.wait()
            break
    running = False


signal.signal(signal.SIGINT, close)
signal.signal(signal.SIGTERM, close)

while running:
    time.sleep(1)

print("\nBye.")
@GrabYourPitchforks GrabYourPitchforks transferred this issue from dotnet/core Mar 25, 2020
@Pilchie Pilchie added the area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI label Mar 25, 2020
@rhyek
Copy link
Author

rhyek commented Mar 25, 2020

Hm. Why was this transferred to aspnetcore? I believe this is a general issue and in fact the sample code is for a console app.

@mkArtakMSFT mkArtakMSFT added feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) investigate labels Jul 14, 2020
@mkArtakMSFT
Copy link
Member

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we will planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@mkArtakMSFT mkArtakMSFT added this to the Next sprint planning milestone Jul 16, 2020
@jkotalik jkotalik added affected-few This issue impacts only small number of customers bug This issue describes a behavior which is not expected - a bug. severity-major This label is used by an internal tool labels Nov 9, 2020 — with ASP.NET Core Issue Ranking
@mkArtakMSFT
Copy link
Member

Hi. Thanks for contacting us.
We're closing this issue as there was not much community interest in this ask for quite a while now.
You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.

@ghost ghost locked as resolved and limited conversation to collaborators Mar 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affected-few This issue impacts only small number of customers area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI bug This issue describes a behavior which is not expected - a bug. feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) investigate severity-major This label is used by an internal tool
Projects
None yet
Development

No branches or pull requests

4 participants