SIGTERM is not handled on Linux

[Flavien]

DNX should wind down and gracefully exit upon receiving a SIGTERM signal on Linux. It seems it is not currently the case.

A simple use case for this: The docker stop command sends a SIGTERM to the process in the container. Dockerized DNX apps can't gracefully shut down.

Moved from aspnet/dnx#3241.

[MaximRouiller]

Related to aspnet/IISIntegration#20?

[pakrym]

• https://github.com/dotnet/corefx/issues/5339

[kouvel]

Is it important for RC2 for this scenario, to handle SIGTERM and have it cause graceful shutdown?

[MaximRouiller]

Useful for lifetime management of the application. Compared to other things? No...

But many users on SO are trying to handle application exiting gracefully or forced and their code never being invoked. The only way it is handled properly is with the CTRL-C shortcut which is not really realistic in a server-side scenario.

Bluemix by IBM sends a SIGTERM when closing an application. That should be considered part of the core scenario (my opinion).

[Tragetaschen]

Hosting currently listens on CTRL+C and on Linux, this translates to SIGINT. So anything that manages that process can end it gracefully by issuing a SIGINT instead of a SIGTERM.

For example in a systemd service unit, I can use KillSignal to change the default SIGTERM to SIGINT. Newer versions of docker have --stop-signal or STOPSIGNAL directive.

I don't think there needs to change anything, but maybe add some documentation.

[Flavien]

I'm not sure if you want to prioritize this for RC2 or RTM, but in any case, yes this should absolutely be fixed. A well behaving process should react accordingly to SIGTERM. This is the path of least surprise.

@Tragetaschen Having to use --stop-signal is unintuitive. Also, Docker Compose doesn't let you use --stop-signal.

[Tragetaschen]

@Flavien Why not? Hosting isn't the only software that behaves like that, so this seems like a strange omission…

A well behaving process (is there a list of properties or a definition?) probably needs to do a couple more things. A notifier that startup has finished and a web server is actually listening comes to mind.

In my application, I'm using the Mono.Posix package to properly use signal handlers (https://gist.github.com/Tragetaschen/435c5bb2062c29753070). This package however, won't work on .NET Core because it relies on Mono providing the necessary runtime bits. I invite everybody to browse through the Mono source code how this is implemented, because doing signal handling right and bridging between Posix (just interrupt any thread in the process at any time) and a multi-threaded, multicast-delegate world is not an easy task, that requires all parts of of the stack to participate (read: it cannot be provided by a library alone)

SIGINT is hidden behind a standard .NET interface (Console.CancelKeyPress) by the runtime and as such becomes an implementation detail that works equally well on Windows and Unix system.

I won't deny the desirability of this, but in my mind that's too broad a feature to be there in 1.0.

[kouvel]

Thanks for the info. There is an issue tracking this: dotnet/coreclr#2688 with some more info on the current plan. It seems unlikely at this point that this would make it into RC2, but let's see.

[tugberkugurlu]

👍 for this.

[muratg]

https://github.com/dotnet/cli/issues/812

[muratg]

Closing this. https://github.com/dotnet/cli/issues/812 is tracking the root cause.