We Keep Coding

dotnet core how to shutdown child process gracefully

I have a dotnet core 2.2 console app.
I hosted it as windows service.
Service starts up another dotnet core WebAPI.
The problem is, how do I gracefully shutdown WebAPI process when the the service is stopped?
Note: I don't want to use Kill() method.
Sample code:
public class MyService : IHostedService, IDisposable
{
private Timer _timer;
static Process webAPI;
public Task StartAsync(CancellationToken cancellationToken)
{
_timer = new Timer(
(e) => StartChildProcess(),
null,
TimeSpan.Zero,
TimeSpan.FromMinutes(1));
return Task.CompletedTask;
}
public void StartChildProcess()
{
try
{
webAPI = new Process();
webAPI.StartInfo.UseShellExecute = false;
webAPI.StartInfo.FileName = #"C:\Project\bin\Debug\netcoreapp2.2\publish\WebAPI.exe";
webAPI.Start();
}
catch (Exception e)
{
// Handle exception
}
}
public Task StopAsync(CancellationToken cancellationToken)
{
// TODO: Add code to stop child process safely
_timer?.Change(Timeout.Infinite, 0);
return Task.CompletedTask;
}
public void Dispose()
{
_timer?.Dispose();
}
}

Technically you could simply call Process.Kill() in order to immediately shut down the process. However, a lot of the time that is not the way to go simply because the WebAPI might be in middle of important operations and you can't really tell when those actions may be happening and Process.Kill() is not really considered "graceful".
What would be most prudent to do is to tell the process that you would like for it to shut down at the earliest convenience and then allow for the WebAPI to clean things up before it exits itself. If you are desiging the WebAPI that is even better because that way you can decide on how to do this. Only calling Kill() when it is absolutely necessary.
You can do that multiple ways of course. Some that come to mind are Sockets that are periodically checked and sending a CTRL+C input to the WebAPI.
public Task StopAsync(CancellationToken cancellationToken)
{
// send request to shut down
// wait for process to exit and free its resources
process.WaitForExit();
process.Close();
process.Dispose();
_timer?.Change(Timeout.Infinite, 0);
return Task.CompletedTask;
}
Of course if this is Async then it wouldn't make sense to wait for it to exit inside of the method so you would simply wait or check if it has exited outside of this method.

There were a lot of threads regarding this issue on github, consider post 7426.
The solution is found here: StartAndStopDotNetCoreApp, the sample code of the program.cs is:
using System;
using System.IO;
using System.Diagnostics;
namespace StartAndStopDotNetCoreApp
{
class Program
{
static void Main(string[] args)
{
string projectPath = #"C:\source\repos\StartAndStopDotNetCoreApp\WebApplication";
string outputPath = #"C:\Temp\WebApplication";
Console.WriteLine("Starting the app...");
var process = new Process();
process.StartInfo.WorkingDirectory = projectPath;
process.StartInfo.FileName = "dotnet";
process.StartInfo.Arguments = $"publish -o {outputPath}";
process.StartInfo.UseShellExecute = false;
process.StartInfo.CreateNoWindow = true;
process.Start();
process.WaitForExit();
process.Close();
process.Dispose();
process = new Process();
process.StartInfo.WorkingDirectory = outputPath;
process.StartInfo.FileName = "dotnet";
process.StartInfo.Arguments = $"{projectPath.Split(#"\")[projectPath.Split(#"\").Length - 1]}.dll";
process.StartInfo.UseShellExecute = false;
process.StartInfo.CreateNoWindow = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();
Console.WriteLine("Press anything to stop...");
Console.Read();
process.Kill();
}
}
}
If this is not what you are looking for, search the mentioned thread for more ways, it offers plenty.

Perhaps it's possible to use the CloseMainWindow method of the System.Diagnostics.Process class? I stumbled upon it when I was looking for a way to send a WM_CLOSE message to another process from C#.
Edit:
CloseMainWindow does not seem to work if the main window is "blocked", for example by an open modal window or a dialog.
You might investigate a strategy for sending a WM_CLOSE or WM_DESTROY message to your app process explicitly. But I cannot guarantee if it will work as you want/expect. I haven't worked with that kind of Windows Messages functionality for a very long time.

Logic to kill a process within a time limit

I want to ensure that my logic is correct here. I want to run a process for timeout seconds, if it runs for longer it should be immediately killed.
The completed flag should reliably indicate whether the process completed as intended, e.g was not killed, and did not crash or throw an exception.
Also, I am not positive if the check to process.HasExited is correct. If process.WaitForExit() returns false and Kill() succeeds, then will process.HasExited always be true? That would be my assumption but I wanted to confirm. Also, what if anything can be done if Kill() fails,
besides just logging?
using (process = new Process())
{
process.EnableRaisingEvents = true;
process.OutputDataReceived += new DataReceivedEventHandler(OnOutputDataReceived);
process.ErrorDataReceived += new DataReceivedEventHandler(OnErrorDataReceived);
process.Exited += new EventHandler(OnExited);
process.StartInfo = startInfo;
process.Start();
process.BeginOutputReadLine();
process.BeginErrorReadLine();
if (!process.WaitForExit(timeout))
{
try
{
process.Kill();
}
catch (Exception e)
{
LogError(e, MethodBase.GetCurrentMethod());
}
finally
{
this.completed = false;
}
}
else
{
if (process.HasExited)
{
this.code = process.ExitCode;
this.completed = true;
}
else
{
this.completed = false;
}
}
}

Yes, the HasExited will always be true in your case.
According to MSDN,
"A value of true for HasExited indicates that the associated process has terminated, either normally or abnormally.[...]A process can terminate independently of your code. If you started the process using this component, the system updates the value of HasExited automatically, even if the associated process exits independently."
However, if your process crashes and terminates before your timeout, then your code will set it as completed anyway. Maybe you should check the exit code, but it can have different meanings for each process:
if (process.ExitCode != 0)
{
this.completed = false;
}
For crashes, there are some approaches here and here, but generally you can't detect crashes for all processes.

We use the following in a .net console app
private void InitTimer()
{
double lInterval = Convert.ToDouble(AppSettings("MaxExecutionTime"));
lInterval = lInterval * 60 * 1000;
tm = new System.Timers.Timer(lInterval); // global timer object
tm.Elapsed += OnTimedEvent;
tm.Enabled = true;
}
public void ThreadProc(object stateinfo)
{
// set error code here
Environment.Exit(0);
}
private void OnTimedEvent(object source, ElapsedEventArgs e)
{
Threading.ThreadPool.QueueUserWorkItem(new Threading.WaitCallback(ThreadProc));
}

In C, you could set an OS alarm using the alarm function. When it expired, a SIGALRM would be sent to your process, which kills it if no handler is set.

You can use this. It is a C# wrapper over the JobObjects functionallity.
The idea behind is (low level outline that is embedded inside the library I mentioned):
Create a job object.
Configure the job object to have a time limit of x seconds.
Create a process and before resuming it assing it to the job object.
Resume the process.
The process will be killed by the operating system when the time passes. YOu usually get notified by a non zero return code, or a callback. The JobObject API itself allows callbacks, not sure about the C# wrapper.
Also using job objects you can restrict memory usage.
On the page I mentioned you can find examples also.
UPDATE
After I wrote the above statements I have found this Kill child process when parent process is killed. They use the JobObjects for another task, but the usage of JobObjects should be the same as for your case.

Running a process inside a worker thread (C#)

I am trying to run several external application from inside my application. Assume that I want to run an application called LongtimeRun.exe for 10 times and each time that this applications runs, it takes around 30s to finish ( total time is 300 sec or 5 minutes!). I also want to give user some progress indication ( for example how many times the application runs).
I can create a batch file and run LongTimeRun.exe there 10 times, but then I am not able to show any progress report.
I have this code which works:
using System.Diagnostics;
using System.IO;
public class CommandProcessor
{
private readonly string binDirectory;
private readonly string workingDirectory;
public CommandProcessor(string workingDirectory, string binFolderName)
{
binDirectory = Path.Combine(FileSystem.ApplicationDirectory, binFolderName);
this.workingDirectory = workingDirectory;
}
public int RunCommand(string command, string argbase, params string[] args)
{
var commandPath = Path.Combine(binDirectory, command);
var formattedArgumets = string.Format(argbase, args);
var myProcess = new Process();
myProcess.EnableRaisingEvents = false;
myProcess.StartInfo.FileName = commandPath;
myProcess.StartInfo.Arguments = formattedArgumets;
myProcess.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
myProcess.StartInfo.WorkingDirectory = this.workingDirectory;
myProcess.Start();
myProcess.WaitForExit();
}
}
When I calling it in tis way:
private void RunCommands()
{
var command = "LongRunCommand.exe";
string binDirectory = Path.Combine(FileSystem.ApplicationDirectory, binFolderName);
var cp = new CommandProcessor(this.workingDirectory, binDirectory);
for(int i=0;i<10;i++)
{
cp.RunCommand(Command, "-i {0}", i);
}
}
The above code is called as part of direct call and blocks the application (the applications seems to hangs during this process.
To solve the hanging problem, I used a backgroundworker as follow:
var worker = new BackgroundWorker();
worker.DoWork += this.WorkerDoWork;
worker.RunWorkerCompleted += this.workerRunWorkerCompleted;
worker.RunWorkerAsync();
and called runcommand inside WorkerDoWork.
Now the application exited after it called this line:
myProcess.WaitForExit();
There is no debug info and exit code is -1.
What is the problem and how can solve it?
Is there any better way to achieve my goal without using BackgroundWorker?

The problem you are encountering is because your BackgroundWorker threads are still running but you application completes its life-cycle and ends (it is not being blocked by them so its path is clear to end) therefore killing these threads.
You need to inform the application NOT to exit while the background threads are still running. You could have a counter that is incremented when each thread starts and then as they complete they can decrement the counter.
Inside your main application thread you could wait until the counter reaches zero before ending the application.
Obviously you will need to take into account locking (i.e. two threads try to decrement counter at the same time) but this should give you a starter.

How to start a Process in a Thread

FURTHER EDIT
the following is not production code - I'm just playing around with a couple of classes trying to figure out how I run processes within threads - or even if that is viable. I've read various definitions on MSDN but am a newbie to threads and processes so any further definitive references to articles would be appreciated
this is fine...
class Program {
static void Main(string[] args) {
Notepad np = new Notepad();
Thread th = new Thread(new ThreadStart(np.startNPprocess));
th.Start();
Console.WriteLine("press [enter] to exit");
Console.ReadLine();
}
}
public class Notepad {
public void startNPprocess() {
Process pr = new Process();
ProcessStartInfo prs = new ProcessStartInfo();
prs.FileName = #"notepad.exe";
pr.StartInfo = prs;
pr.Start();
}
}
this isn't...
class Program {
static void Main(string[] args) {
Process pr = new Process();
ProcessStartInfo prs = new ProcessStartInfo();
prs.FileName = #"notepad.exe";
pr.StartInfo = prs;
ThreadStart ths = new ThreadStart(pr.Start);
Thread th = new Thread(ths);
th.Start();
Console.WriteLine("press [enter] to exit");
Console.ReadLine();
}
}
Why does the second not do the same as the first? In the second script I'm trying to pass Process.Start using the Threadstart delegate ...I thought this would be ok as its a void method?
Is the first script the only option or can I change the second slightly so that it effectively does the same job as the first i.e start an instance of Notepad in a specified thread?
EDIT
Some background as to why I'm playing around with this code: ultimately I need to build an application which will be running several Excel processes simultaneously. These processes can be troublesome when VBA errors as it results in a dialogbox. So I thought if each process was running in a thread then if a particular thread has been running for too long then I could kill the thread. I'm a newbie to Threads/Processes so basically playing around with possibilities at the moment.

A ThreadStart expects a delegate that returns void. Process.Start returns bool, so is not a compatible signature. You can swallow the return value in by using a lambda that gives you a delegate of the correct return type (i.e. void) as follows:
Process pr = new Process();
ProcessStartInfo prs = new ProcessStartInfo();
prs.FileName = #"notepad.exe";
pr.StartInfo = prs;
ThreadStart ths = new ThreadStart(() => pr.Start());
Thread th = new Thread(ths);
th.Start();
...but it's probably advisable to check the return value:
ThreadStart ths = new ThreadStart(() => {
bool ret = pr.Start();
//is ret what you expect it to be....
});
Of course, a process starts in a new process (a completely separate bunch of threads), so starting it on a thread is completely pointless.

you can make changes like
ThreadStart ths = new ThreadStart(delegate() { pr.Start(); });

Just start the process normally using this code:
Process.Start("notepad.exe");
There is no point and no benefits in creating a thread to run a new process. It's like running a batch file that executes "cmd.exe" when you can directly execute "cmd.exe"... you are just doing more than what's necessary for nothing. Don't reinvent the wheel and play easy :P

Not answering directly the OP, but as this thread helped me track the right direction, I do want to answer this:
"starting it on a thread is completely pointless"
I have a .Net server that uses NodeJS as its TCP socket manager. I wanted the NodeJS to write to the same output as the .Net server and they both run in parallel. So opening in a new thread allowed me to use
processNodeJS.BeginErrorReadLine()
processNodeJS.BeginOutputReadLine()
processNodeJS.WaitForExit()
while not blocking the main thread of the .Net server.
I hope it makes sense to someone and if you have a better way to implement what I've just described, I'll be more than happy to hear.

You can start the process in another thread by using the start keyword like below this cod:
Process.Start("start notepad.exe");
in this way, your GUI program doesn't freeze when you run the notepad.

Async process start and wait for it to finish

I am new to the thread model in .NET. What would you use to:
Start a process that handles a file (process.StartInfo.FileName = fileName;).
Wait for the user to close the process OR abandon the thread after some time.
If the user closed the process, delete the file.
Starting the process and waiting should be done on a different thread than the main thread, because this operation should not affect the application.
Example:
My application produces an html report. The user can right click somewhere and say "View Report" - now I retrieve the report contents in a temporary file and launch the process that handles html files i.e. the default browser. The problem is that I cannot cleanup, i.e. delete the temp file.

"and waiting must be async" - I'm not trying to be funny, but isn't that a contradiction in terms? However, since you are starting a Process, the Exited event may help:
ProcessStartInfo startInfo = null;
Process process = Process.Start(startInfo);
process.EnableRaisingEvents = true;
process.Exited += delegate {/* clean up*/};
If you want to actually wait (timeout etc), then:
if(process.WaitForExit(timeout)) {
// user exited
} else {
// timeout (perhaps process.Kill();)
}
For waiting async, perhaps just use a different thread?
ThreadPool.QueueUserWorkItem(delegate {
Process process = Process.Start(startInfo);
if(process.WaitForExit(timeout)) {
// user exited
} else {
// timeout
}
});

Adding an advanced alternative to this old question. If you want to wait for a process to exit without blocking any thread and still support timeouts, try the following:
public static Task<bool> WaitForExitAsync(this Process process, TimeSpan timeout)
{
ManualResetEvent processWaitObject = new ManualResetEvent(false);
processWaitObject.SafeWaitHandle = new SafeWaitHandle(process.Handle, false);
TaskCompletionSource<bool> tcs = new TaskCompletionSource<bool>();
RegisteredWaitHandle registeredProcessWaitHandle = null;
registeredProcessWaitHandle = ThreadPool.RegisterWaitForSingleObject(
processWaitObject,
delegate(object state, bool timedOut)
{
if (!timedOut)
{
registeredProcessWaitHandle.Unregister(null);
}
processWaitObject.Dispose();
tcs.SetResult(!timedOut);
},
null /* state */,
timeout,
true /* executeOnlyOnce */);
return tcs.Task;
}
Again, the advantage to this approach compared to the accepted answer is that you're not blocking any threads, which reduces the overhead of your app.

Try the following code.
public void KickOffProcess(string filePath) {
var proc = Process.Start(filePath);
ThreadPool.QueueUserWorkItem(new WaitCallBack(WaitForProc), proc);
}
private void WaitForProc(object obj) {
var proc = (Process)obj;
proc.WaitForExit();
// Do the file deletion here
}

The .NET 5 introduced the new API Process.WaitForExitAsync, that allows to wait asynchronously for the completion of a process. It offers the same functionality with the existing Process.WaitForExit, with the only difference being that the waiting is asynchronous, so it does not block the calling thread.
Usage example:
private async void button1_Click(object sender, EventArgs e)
{
string filePath = Path.Combine
(
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
Guid.NewGuid().ToString() + ".txt"
);
File.WriteAllText(filePath, "Hello World!");
try
{
using Process process = new();
process.StartInfo.FileName = "Notepad.exe";
process.StartInfo.Arguments = filePath;
process.Start();
await process.WaitForExitAsync();
}
finally
{
File.Delete(filePath);
}
MessageBox.Show("Done!");
}
In the above example the UI remains responsive while the user interacts with the opened file. The UI thread would be blocked if the WaitForExit had been used instead.

I would probably not use a separate process for opening a file. Instead, I'd probably utilize a background thread (if I thought the operation was going to take a long time and possible block the UI thread).
private delegate void FileOpenDelegate(string filename);
public void OpenFile(string filename)
{
FileOpenDelegate fileOpenDelegate = OpenFileAsync;
AsyncCallback callback = AsyncCompleteMethod;
fileOpenDelegate.BeginInvoke(filename, callback, state);
}
private void OpenFileAsync(string filename)
{
// file opening code here, and then do whatever with the file
}
Of course, this is not a good working example (it returns nothing) and I haven't shown how the UI gets updated (you have to use BeginInvoke at the UI level because a background thread cannot update the UI thread). But this approach is generally how I go about handling asynchronous operations in .Net.

You can use the Exited event in Process class
ProcessStartInfo info = new ProcessStartInfo();
info.FileName = "notepad.exe";
Process process = Process.Start(info);
process.Exited += new EventHandler(process_Exited);
Console.Read();
and in that event you can handle the operations you mentioned