Process.Start() leaving <defunct> child process behind


I’m building an ASP.Net Core (netcore 1.1) application deployed on CentOS 7.2.

I have an action which calls an external process (a console application also built with .net core) through System.Diagnostics.Process and doesn’t wait for it to exit before returning.

The problem is that the said process becomes and stays even after it has finished executing. I don’t want to wait for it to exit because that process could take several minutes to do its job.

Here is a sample code

//The process is writing its progress to a sqlite database using a
//previously generated guid which is used later in order to check
//the task's progress

ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = "/bin/sh -c \"/path/to/process/executable -args\"";
psi.UseShellExecute = true;
psi.WorkingDirectory = "/path/to/process/";
psi.RedirectStandardOutput = false;
psi.RedirectStandardError = false;
psi.RedirectStandardInput = false;

using(Process proc = new Process({ StartInfo = psi }))

The process starts and does its job. It writes its progress for his specific task to a sqlite database. I can then probe that database to check out the progress.

Everything runs fine, but I can see after the process execution with ps -ef |grep executable that it’s listed as and I have no other way to get rid of it than by killing it’s parent process which is my CoreMVC application.

Is there a way to start a process within a .NET Core application without waiting for it to exit, and force the parent application to reap the resulting child process ?


It sounds to me like the issue is that the process does not exit after it finishes it work. Can’t you fix the process so that it exits properly?


Thanks for the reply, I created this post almost 2 month ago and it eventually got approved yesterday. I found the solution on my original stackoverflow post here :

using(Process proc = new Process(
        StartInfo = psi, 
        EnableRaisingEvents = true //Allow the process to raise events, 
                                   //which I guess triggers the reaping of 
                                   //the child process by the parent 

It looks like allowing the process to raise events triggers the reaping of the sub process once it has exited.

.NET Foundation Website | Blog | Projects | Code of Conduct