Add support in dotnet run for pid files

[victorhurdugaci]

Add support for dropping a pid file. The watcher needs it because otherwise it cannot kill the process started by dotnet run

cc @piotrpMSFT @anurse

[ThatRendle]

I've been wishing CoreFx on POSIX systems had a way to listen for SIG*.

[Petermarcu]

@stephentoub, @Priya91 , Thoughts? We've had this item in the backlog for a while. https://github.com/dotnet/corefx/issues/3188

[stephentoub]

I'm not following the thread, but if the concern is around lack of graceful shutdown in response to SIGTERM, there's https://github.com/dotnet/coreclr/issues/2688

[victorhurdugaci]

@stephentoub we need this feature for dotnet watch: watch calls dotnet run which starts the application that was built. The problem is that the watcher has no idea about the second process and when it kills dotnet run, the second process is orphaned. With the pid file, run will let the watcher know what's the actual process being watched.

[stephentoub]

@victorhurdugaci, thanks, but I'm not understanding the connection to the comments about graceful shutdown and signal handling. Can you elaborate? What feature of corefx/coreclr is desired here to address this situation?

[victorhurdugaci]

@stephentoub we just need a cross platform mechanism to signal and gracefully shutdown a process. That way, dotnet run could stop the child process and the watcher wouldn't be aware of it. Today, Process.Kill doesn't give the chance to do any cleanup.

[stephentoub]

Ah, I understand now.

Well, using AssemblyLoadContext.Unloading (https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Loader/ref/System.Runtime.Loader.cs#L37) you can register to be notified when your process is gracefully exiting (e.g. because Environment.Exit is called), and with https://github.com/dotnet/coreclr/issues/2688 (cc: @kouvel) this should be triggered in response to a SIGTERM signal.

It sounds then like then you're simply wanting the ability to send a SIGTERM on Unix, and you can do so with a P/Invoke to kill(pid, 15) conditionally when RuntimeInformation.IsOSPlatform(OSPlatform.Windows) is false. I agree we should at some point wrap kill to allow for sending arbitrary signals without having to write your own P/Invoke (that's part of what https://github.com/dotnet/corefx/issues/3188 is about), but it's a very easy P/Invoke to write, and if we did wrap it in a new corefx library, it would be platform-specific, since signals are platform-specific. I'm not even sure what a cross-platform "please shutdown gracefully that process over there" API would look like... what would you do on Windows to request another process gracefully shut down? In particular, how would you do it for a process that's not running a message loop to receive WM_QUIT or WM_CLOSE messages?

[stephentoub]

Or, are you asking for something else, like the ability to manually send (the equivalent of) ctrl-C to another process on both Windows and Unix?

[davidfowl]

Kill and entire process tree

[victorhurdugaci]

@stephentoub @davidfowl yup, ultimately the goal is to kill an entire process tree

[stephentoub]

Since you're already in the world of launching this or that utility, have you considered just launching the various utilities to kill a whole process tree, e.g. pkill -TERM -P pid on Unix and taskkill /t /pid pid on Windows?

[victorhurdugaci]

@stephentoub that's an interesting idea which might work. Let me give it a try and maybe we don't need this PR after all

[victorhurdugaci]

@stephentoub that seems to work. I'll close this PR for now

[muratg]

@stephentoub Apparently taskkill.exe doesn't exist on Nano... any suggestions there?

[stephentoub]

Apparently taskkill.exe doesn't exist on Nano... any suggestions there?

I don't know what utilities are available there.

I don't have a great suggestion with what's available... even in the full framework, there's no Process.Kill(bool recursive) or anything like that, and folks have resorted either to using taskkill.exe or to using WMI. If Process exposed a ParentId, then that could be used to implement this as well, as one could then determine from the list of processes all of the processes which should be killed individually... unfortunately again there's no such property in the framework (FWIW, my initial guess at how such a potential future recursive Kill would be implemented is basically that way). cc: @pallavit in case she has any other ideas.

There are other workarounds one could imagine. For example, the parent process could pass its ID (Process.GetCurrentProcess().Id) to the child process, which could then poll to see if the parent is still around, and if it's not, Environment.Exit(). Not ideal, but potentially workable.