How to make child process die after parent exits

Question

Suppose I have a process which spawns exactly one child process  Now when the parent process exits for whatever reason  normally or abnormally  by kill   C  assert failure or anything else  I want the child process to die  How to do that correctly     Some similar question on stackoverflow     asked earlier  How can I cause a child process to exit when the parent does   asked later  Are child processes created with fork   automatically killed when the parent is killed      Some similar question on stackoverflow for Windows      How do I automatically destroy child processes in Windows    Kill child process when parent process is killed

User · Answer

I have achieved this in the past by running the "original" code in the "child" and the "spawned" code in the "parent" (that is: you reverse the usual sense of the test after fork()). Then trap SIGCHLD in the "spawned" code...

May not be possible in your case, but cute when it works.

User · Answer

As other people have pointed out  relying on the parent pid to become 1 when the parent exits is non-portable  Instead of waiting for a specific parent process ID  just wait for the ID to change   pit t pid   getpid    switch  fork          case -1                abort       or whatever                 default                   parent            exit 0             case 0                   child                                  Wait for parent to exit    while  getppid      pid          Add a micro-sleep as desired if you don t want to poll at full speed   This option seems simpler to me than using a pipe or relying on signals

User · Answer

Some posters have already mentioned pipes and kqueue   In fact you can also create a pair of connected Unix domain sockets by the socketpair   call   The socket type should be SOCK STREAM   Let us suppose you have the two socket file descriptors fd1  fd2   Now fork   to create the child process  which will inherit the fds   In the parent you close fd2 and in the child you close fd1   Now each process can poll   the remaining open fd on its own end for the POLLIN event   As long as each side doesn t explicitly close   its fd during normal lifetime  you can be fairly sure that a POLLHUP flag should indicate the other s termination  no matter clean or not    Upon notified of this event  the child can decide what to do  e g  to die     include  lt unistd h gt   include  lt stdlib h gt   include  lt sys types h gt   include  lt sys socket h gt   include  lt poll h gt   include  lt stdio h gt   int main int argc  char    argv        int sv 2             sv 0  for parent  sv 1  for child        socketpair AF UNIX  SOCK STREAM  0  sv        pid t pid   fork         if   pid  gt  0         parent            close sv 1            fprintf stderr   parent  pid    d n   getpid             sleep 100           exit 0          else               child            close sv 0            fprintf stderr   child  pid    d n   getpid              struct pollfd mon          mon fd   sv 1           mon events   POLLIN           poll  amp mon  1  -1           if   mon revents  amp  POLLHUP               fprintf stderr   child  parent hung up n            exit 0             You can try compiling the above proof-of-concept code  and run it in a terminal like   a out  amp    You have roughly 100 seconds to experiment with killing the parent PID by various signals  or it will simply exit   In either case  you should see the message  child  parent hung up    Compared with the method using SIGPIPE handler  this method doesn t require trying the write   call   This method is also symmetric  i e  the processes can use the same channel to monitor each other s existence   This solution calls only the POSIX functions   I tried this in Linux and FreeBSD   I think it should work on other Unixes but I haven t really tested   See also    unix 7  of Linux man pages  unix 4  for FreeBSD  poll 2   socketpair 2   socket 7  on Linux

User · Answer

As other people have pointed out  relying on the parent pid to become 1 when the parent exits is non-portable  Instead of waiting for a specific parent process ID  just wait for the ID to change   pit t pid   getpid    switch  fork          case -1                abort       or whatever                 default                   parent            exit 0             case 0                   child                                  Wait for parent to exit    while  getppid      pid          Add a micro-sleep as desired if you don t want to poll at full speed   This option seems simpler to me than using a pipe or relying on signals

User · Answer

Does the child process have a pipe to from the parent process  If so  you d receive a SIGPIPE if writing  or get EOF when reading - these conditions could be detected

User · Answer

I don t believe it s possible to guarantee that using only standard POSIX calls   Like real life  once a child is spawned  it has a life of its own   It is possible  for the parent process to catch most possible termination events  and attempt to kill the child process at that point  but there s always some that can t be caught   For example  no process can catch a SIGKILL   When the kernel handles this signal it will kill the specified process with no notification to that process whatsoever   To extend the analogy - the only other standard way of doing it is for the child to commit suicide when it finds that it no longer has a parent   There is a Linux-only way of doing it with prctl 2  - see other answers

User · Answer

Child can ask kernel to deliver SIGHUP  or other signal  when parent dies by specifying option PR SET PDEATHSIG in prctl   syscall like this   prctl PR SET PDEATHSIG  SIGHUP    See man 2 prctl for details   Edit  This is Linux-only

User · Answer

Inspired by another answer here  I came up with the following all-POSIX solution  The general idea is to create an intermediate process between the parent and the child  that has one purpose  Notice when the parent dies  and explicitly kill the child   This type of solution is useful when the code in the child can t be modified   int p 2   pipe p   pid t child   fork    if  child    0        close p 1       close write end of pipe     setpgid 0  0      prevent  C in parent from stopping this process     child   fork        if  child    0            close p 0       close read end of pipe  don t need it here          exec    child process here              exit 1             read p 0   1      returns when parent exits for any reason     kill child  9       exit 1       There are two small caveats with this method    If you deliberately kill the intermediate process  then the child won t be killed when the parent dies  If the child exits before the parent  then the intermediate process will try to kill the original child pid  which could now refer to a different process   This could be fixed with more code in the intermediate process     As an aside  the actual code I m using is in Python  Here it is for completeness   def run  args        r  w    os pipe       child   os fork       if child    0          os close w          os setpgid 0  0          child   os fork           if child    0              os close r              os execl args 0    args              os  exit 1          os read r  1          os kill child  9          os  exit 1      os close r

User · Answer

Under POSIX  the exit     exit   and  Exit   functions are defined to    If the process is a controlling process  the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process    So  if you arrange for the parent process to be a controlling process for its process group  the child should get a SIGHUP signal when the parent exits   I m not absolutely sure that happens when the parent crashes  but I think it does   Certainly  for the non-crash cases  it should work fine   Note that you may have to read quite a lot of fine print - including the Base Definitions  Definitions  section  as well as the System Services information for exit   and setsid   and setpgrp   - to get the complete picture    So would I

User · Answer

For completeness sake  On macOS you can use kqueue   void noteProcDeath      CFFileDescriptorRef fdref       CFOptionFlags callBackTypes       void  info            LOG DEBUG   noteProcDeath             struct kevent kev      int fd   CFFileDescriptorGetNativeDescriptor fdref       kevent fd  NULL  0   amp kev  1  NULL          take action on death of process here     unsigned int dead pid    unsigned int kev ident       CFFileDescriptorInvalidate fdref       CFRelease fdref      the CFFileDescriptorRef is no longer of any use in this example      int our pid   getpid           when our parent dies we die as well        LOG INFO   exit  parent process  pid  u  died  no need for us  pid  i  to stick around   dead pid  our pid       exit EXIT SUCCESS       void suicide if we become a zombie int parent pid           int parent pid   getppid           int our pid   getpid           LOG ERROR   suicide if we become a zombie    parent process  pid  u  that we monitor  our pid  i   parent pid  our pid        int fd   kqueue        struct kevent kev      EV SET  amp kev  parent pid  EVFILT PROC  EV ADD EV ENABLE  NOTE EXIT  0  NULL       kevent fd   amp kev  1  NULL  0  NULL       CFFileDescriptorRef fdref   CFFileDescriptorCreate kCFAllocatorDefault  fd  true  noteProcDeath  NULL       CFFileDescriptorEnableCallBacks fdref  kCFFileDescriptorReadCallBack       CFRunLoopSourceRef source   CFFileDescriptorCreateRunLoopSource kCFAllocatorDefault  fdref  0       CFRunLoopAddSource CFRunLoopGetMain    source  kCFRunLoopDefaultMode       CFRelease source

User · Answer

This solution worked for me    Pass stdin pipe to child - you don t have to write any data into the stream  Child reads indefinitely from stdin until EOF  An EOF signals that the parent has gone  This is foolproof and portable way to detect when the parent has gone  Even if parent crashes  OS will close the pipe    This was for a worker-type process whose existence only made sense when the parent was alive

User · Answer

Child can ask kernel to deliver SIGHUP  or other signal  when parent dies by specifying option PR SET PDEATHSIG in prctl   syscall like this   prctl PR SET PDEATHSIG  SIGHUP    See man 2 prctl for details   Edit  This is Linux-only

User · Answer

Install a trap handler to catch SIGINT  which kills off your child process if it s still alive  though other posters are correct that it won t catch SIGKILL    Open a  lockfile with exclusive access and have the child poll on it trying to open it - if the open succeeds  the child process should exit

User · Answer

Under POSIX  the exit     exit   and  Exit   functions are defined to    If the process is a controlling process  the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process    So  if you arrange for the parent process to be a controlling process for its process group  the child should get a SIGHUP signal when the parent exits   I m not absolutely sure that happens when the parent crashes  but I think it does   Certainly  for the non-crash cases  it should work fine   Note that you may have to read quite a lot of fine print - including the Base Definitions  Definitions  section  as well as the System Services information for exit   and setsid   and setpgrp   - to get the complete picture    So would I

User · Answer

I don t believe it s possible to guarantee that using only standard POSIX calls   Like real life  once a child is spawned  it has a life of its own   It is possible  for the parent process to catch most possible termination events  and attempt to kill the child process at that point  but there s always some that can t be caught   For example  no process can catch a SIGKILL   When the kernel handles this signal it will kill the specified process with no notification to that process whatsoever   To extend the analogy - the only other standard way of doing it is for the child to commit suicide when it finds that it no longer has a parent   There is a Linux-only way of doing it with prctl 2  - see other answers

User · Answer

If parent dies  PPID of orphans change to 1 - you only need to check your own PPID  In a way  this is polling  mentioned above  here is shell piece for that   check parent            parent  ps -f awk   2    PID  print  3           echo  parent  parent        let parent  parent 0       if     parent -eq 1     then         echo  parent is dead  exiting          exit        fi     PID    cnt 0 while    1   1     do   check parent       something done

User · Answer

If you send a signal to the pid 0  using for instance  kill 0  2      SIGINT      that signal is sent to the entire process group  thus effectively killing the child   You can test it easily with something like    cat  amp  amp  kill 0    python   If you then press  D  you ll see the text  Terminated  as an indication that the Python interpreter have indeed been killed  instead of just exited because of stdin being closed

User · Answer

I think a quick and dirty way is to create a pipe between child and parent  When parent exits  children will receive a SIGPIPE

User · Answer

I found 2 solutions  both not perfect   1 Kill all children by kill -pid  when received SIGTERM signal  Obviously  this solution can not handle  kill -9   but it do work for most case and very simple because it need not to remember all child processes        var childProc   require  child process   spawn  tail     -f     dev null     stdio  ignore          var counter 0      setInterval function          console log  c       counter          1000        if  process platform slice 0 3      win           function killMeAndChildren                          On Linux Unix Include Mac OS X   kill  -pid  will kill process group  usually           the process itself and children            On Windows  an JOB object has been applied to current process and children            so all children will be terminated if current process dies by anyway                     console log  kill process group            process kill -process pid   SIGKILL                              When you use  kill pid of this process   this callback will be called                process on  SIGTERM   function err           console log  SIGTERM            killMeAndChildren                       By same way  you can install  exit  handler like above way if you call process exit somewhere  Note  Ctrl C and sudden crash have automatically been processed by OS to kill process group  so no more here   2 Use chjj pty js to spawn your process with controlling terminal attached  When you kill current process by anyway even kill -9  all child processes will be automatically killed too  by OS    I guess that because current process hold another side of the terminal  so if current process dies  the child process will get SIGPIPE so dies        var pty   require  pty js           var term       pty spawn  any child process      any arguments             name   xterm-color         cols  80        rows  30        cwd  process cwd          env  process env               optionally you can install data handler     term on  data   function data          process stdout write data               term write

User · Answer

I have achieved this in the past by running the "original" code in the "child" and the "spawned" code in the "parent" (that is: you reverse the usual sense of the test after fork()). Then trap SIGCHLD in the "spawned" code...

May not be possible in your case, but cute when it works.

User · Answer

Inspired by another answer here  I came up with the following all-POSIX solution  The general idea is to create an intermediate process between the parent and the child  that has one purpose  Notice when the parent dies  and explicitly kill the child   This type of solution is useful when the code in the child can t be modified   int p 2   pipe p   pid t child   fork    if  child    0        close p 1       close write end of pipe     setpgid 0  0      prevent  C in parent from stopping this process     child   fork        if  child    0            close p 0       close read end of pipe  don t need it here          exec    child process here              exit 1             read p 0   1      returns when parent exits for any reason     kill child  9       exit 1       There are two small caveats with this method    If you deliberately kill the intermediate process  then the child won t be killed when the parent dies  If the child exits before the parent  then the intermediate process will try to kill the original child pid  which could now refer to a different process   This could be fixed with more code in the intermediate process     As an aside  the actual code I m using is in Python  Here it is for completeness   def run  args        r  w    os pipe       child   os fork       if child    0          os close w          os setpgid 0  0          child   os fork           if child    0              os close r              os execl args 0    args              os  exit 1          os read r  1          os kill child  9          os  exit 1      os close r

User · Answer

Does the child process have a pipe to from the parent process  If so  you d receive a SIGPIPE if writing  or get EOF when reading - these conditions could be detected

User · Answer

For completeness sake  On macOS you can use kqueue   void noteProcDeath      CFFileDescriptorRef fdref       CFOptionFlags callBackTypes       void  info            LOG DEBUG   noteProcDeath             struct kevent kev      int fd   CFFileDescriptorGetNativeDescriptor fdref       kevent fd  NULL  0   amp kev  1  NULL          take action on death of process here     unsigned int dead pid    unsigned int kev ident       CFFileDescriptorInvalidate fdref       CFRelease fdref      the CFFileDescriptorRef is no longer of any use in this example      int our pid   getpid           when our parent dies we die as well        LOG INFO   exit  parent process  pid  u  died  no need for us  pid  i  to stick around   dead pid  our pid       exit EXIT SUCCESS       void suicide if we become a zombie int parent pid           int parent pid   getppid           int our pid   getpid           LOG ERROR   suicide if we become a zombie    parent process  pid  u  that we monitor  our pid  i   parent pid  our pid        int fd   kqueue        struct kevent kev      EV SET  amp kev  parent pid  EVFILT PROC  EV ADD EV ENABLE  NOTE EXIT  0  NULL       kevent fd   amp kev  1  NULL  0  NULL       CFFileDescriptorRef fdref   CFFileDescriptorCreate kCFAllocatorDefault  fd  true  noteProcDeath  NULL       CFFileDescriptorEnableCallBacks fdref  kCFFileDescriptorReadCallBack       CFRunLoopSourceRef source   CFFileDescriptorCreateRunLoopSource kCFAllocatorDefault  fdref  0       CFRunLoopAddSource CFRunLoopGetMain    source  kCFRunLoopDefaultMode       CFRelease source

User · Answer

Some posters have already mentioned pipes and kqueue   In fact you can also create a pair of connected Unix domain sockets by the socketpair   call   The socket type should be SOCK STREAM   Let us suppose you have the two socket file descriptors fd1  fd2   Now fork   to create the child process  which will inherit the fds   In the parent you close fd2 and in the child you close fd1   Now each process can poll   the remaining open fd on its own end for the POLLIN event   As long as each side doesn t explicitly close   its fd during normal lifetime  you can be fairly sure that a POLLHUP flag should indicate the other s termination  no matter clean or not    Upon notified of this event  the child can decide what to do  e g  to die     include  lt unistd h gt   include  lt stdlib h gt   include  lt sys types h gt   include  lt sys socket h gt   include  lt poll h gt   include  lt stdio h gt   int main int argc  char    argv        int sv 2             sv 0  for parent  sv 1  for child        socketpair AF UNIX  SOCK STREAM  0  sv        pid t pid   fork         if   pid  gt  0         parent            close sv 1            fprintf stderr   parent  pid    d n   getpid             sleep 100           exit 0          else               child            close sv 0            fprintf stderr   child  pid    d n   getpid              struct pollfd mon          mon fd   sv 1           mon events   POLLIN           poll  amp mon  1  -1           if   mon revents  amp  POLLHUP               fprintf stderr   child  parent hung up n            exit 0             You can try compiling the above proof-of-concept code  and run it in a terminal like   a out  amp    You have roughly 100 seconds to experiment with killing the parent PID by various signals  or it will simply exit   In either case  you should see the message  child  parent hung up    Compared with the method using SIGPIPE handler  this method doesn t require trying the write   call   This method is also symmetric  i e  the processes can use the same channel to monitor each other s existence   This solution calls only the POSIX functions   I tried this in Linux and FreeBSD   I think it should work on other Unixes but I haven t really tested   See also    unix 7  of Linux man pages  unix 4  for FreeBSD  poll 2   socketpair 2   socket 7  on Linux

User · Answer

I m trying to solve the same problem  and since my program must run on OS X  the Linux-only solution didn t work for me   I came to the same conclusion as the other people on this page -- there isn t a POSIX-compatible way of notifying a child when a parent dies  So I kludged up the next-best thing -- having the child poll   When a parent process dies  for any reason  the child s parent process becomes process 1  If the child simply polls periodically  it can check if its parent is 1  If it is  the child should exit   This isn t great  but it works  and it s easier than the TCP socket lockfile polling solutions suggested elsewhere on this page

User · Answer

I managed to do a portable  non-polling solution with 3 processes by abusing terminal control and sessions  The trick is   process A is started process A creates a pipe P  and never reads from it  process A forks into process B process B creates a new session process B allocates a virtual terminal for that new session process B installs SIGCHLD handler to die when the child exits process B sets a SIGPIPE handler process B forks into process C process C does whatever it needs  e g  exec  s the unmodified binary or runs whatever logic  process B writes to pipe P  and blocks that way  process A wait  s on process B and exits when it dies  That way   if process A dies  process B gets a SIGPIPE and dies if process B dies  process A s wait   returns and dies  process C gets a SIGHUP  because when the session leader of a session with a terminal attached dies  all processes in the foreground process group get a SIGHUP  if process C dies  process B gets a SIGCHLD and dies  so process A dies  Shortcomings   process C can t handle SIGHUP process C will be run in a different session process C can t use session process group API because it ll break the brittle setup creating a terminal for every such operation is not the best idea ever

User · Answer

Under POSIX  the exit     exit   and  Exit   functions are defined to    If the process is a controlling process  the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process    So  if you arrange for the parent process to be a controlling process for its process group  the child should get a SIGHUP signal when the parent exits   I m not absolutely sure that happens when the parent crashes  but I think it does   Certainly  for the non-crash cases  it should work fine   Note that you may have to read quite a lot of fine print - including the Base Definitions  Definitions  section  as well as the System Services information for exit   and setsid   and setpgrp   - to get the complete picture    So would I

User · Answer

Even though 7 years have passed I ve just run into this issue as I m running SpringBoot application that needs to start webpack-dev-server during development and needs to kill it when the backend process stops   I try to use Runtime getRuntime   addShutdownHook but it worked on Windows 10 but not on Windows 7   I ve change it to use a dedicated thread that waits for the process to quit or for InterruptedException which seems to work correctly on both Windows versions   private void startWebpackDevServer         String cmd   isWindows      cmd  c gradlew webPackStart     gradlew webPackStart       logger info  webpack dev-server     cmd        Thread thread   new Thread    - gt             ProcessBuilder pb   new ProcessBuilder cmd split                pb redirectOutput ProcessBuilder Redirect INHERIT           pb redirectError ProcessBuilder Redirect INHERIT           pb directory new File                 Process process   null          try                  Start the node process             process   pb start                    Wait for the node process to quit  blocking              process waitFor                    Ensure the node process is killed             process destroyForcibly                System setProperty WEBPACK SERVER PROPERTY   true              catch  InterruptedException   IOException e                   Ensure the node process is killed                 InterruptedException is thrown when the main process exit              logger info  killing webpack dev-server   e               if  process    null                    process destroyForcibly                                          thread start

User · Answer

Historically  from UNIX v7  the process system has detected orphanity of processes by checking a process  parent id   As I say  historically  the init 8  system process is a special process by only one reason  It cannot die   It cannot die because the kernel algorithm to deal with assigning a new parent process id  depends on this fact   when a process executes its exit 2  call  by means of a process system call or by external task as sending it a signal or the like  the kernel reassigns all children of this process the id of the init process as their parent process id   This leads to the most easy test  and most portable way of knowing if a process has got orphan   Just check the result of the getppid 2  system call and if it is the process id of the init 2  process then the process got orphan before the system call   Two issues emerge from this approach that can lead to issues    first  we have the possibility of changing the init process to any user process  so How can we assure that the init process will always be parent of all orphan processes  Well  in the exit system call code there s a explicit check to see if the process executing the call is the init process  the process with pid equal to 1  and if that s the case  the kernel panics  It should not be able anymore to maintain the process hierarchy  so it is not permitted for the init process to do an exit 2  call  second  there s a race condition in the basic test exposed above   Init process  id is assumed historically to be 1  but that s not warranted by the POSIX approach  that states  as exposed in other response  that only a system s process id is reserved for that purpose  Almost no posix implementation does this  and you can assume in original unix derived systems that having 1 as response of getppid 2  system call is enough to assume the process is orphan   Another way to check is to make a getppid 2  just after the fork and compare that value with the result of a new call   This simply doesn t work in all cases  as both call are not atomic together  and the parent process can die after the fork 2  and before the first getppid 2  system call   The processparent id only changes once  when its parent does anexit 2 call  so this should be enough to check if thegetppid 2 result changed between calls to see that parent process has exit   This test is not valid for the actual children of the init process  because they are always children ofinit 8    but you can assume safely these processes as having no parent either  except when you substitute in a system the init process

User · Answer

I ve passed parent pid using environment to the child  then periodically checked if  proc  ppid exists from the child

User · Answer

In case it is relevant to anyone else  when I spawn JVM instances in forked child processes from C    the only way I could get the JVM instances to terminate properly after the parent process completed was to do the following  Hopefully someone can provide feedback in the comments if this wasn t the best way to do this   1  Call prctl PR SET PDEATHSIG  SIGHUP  on the forked child process as suggested before launching the Java app via execv  and   2  Add a shutdown hook to the Java application that polls until its parent PID equals 1  then do a hard Runtime getRuntime   halt 0   The polling is done by launching a separate shell that runs the ps command  See  How do I find my PID in Java or JRuby on Linux     EDIT 130118   It seems that was not a robust solution  I m still struggling a bit to understand the nuances of what s going on  but I was still sometimes getting orphan JVM processes when running these applications in screen SSH sessions    Instead of polling for the PPID in the Java app  I simply had the shutdown hook perform cleanup followed by a hard halt as above  Then I made sure to invoke waitpid in the C   parent app on the spawned child process when it was time to terminate everything  This seems to be a more robust solution  as the child process ensures that it terminates  while the parent uses existing references to make sure that its children terminate  Compare this to the previous solution which had the parent process terminate whenever it pleased  and had the children try to figure out if they had been orphaned before terminating

User · Answer

I m trying to solve the same problem  and since my program must run on OS X  the Linux-only solution didn t work for me   I came to the same conclusion as the other people on this page -- there isn t a POSIX-compatible way of notifying a child when a parent dies  So I kludged up the next-best thing -- having the child poll   When a parent process dies  for any reason  the child s parent process becomes process 1  If the child simply polls periodically  it can check if its parent is 1  If it is  the child should exit   This isn t great  but it works  and it s easier than the TCP socket lockfile polling solutions suggested elsewhere on this page

User · Answer

I don t believe it s possible to guarantee that using only standard POSIX calls   Like real life  once a child is spawned  it has a life of its own   It is possible  for the parent process to catch most possible termination events  and attempt to kill the child process at that point  but there s always some that can t be caught   For example  no process can catch a SIGKILL   When the kernel handles this signal it will kill the specified process with no notification to that process whatsoever   To extend the analogy - the only other standard way of doing it is for the child to commit suicide when it finds that it no longer has a parent   There is a Linux-only way of doing it with prctl 2  - see other answers

User · Answer

I found 2 solutions  both not perfect   1 Kill all children by kill -pid  when received SIGTERM signal  Obviously  this solution can not handle  kill -9   but it do work for most case and very simple because it need not to remember all child processes        var childProc   require  child process   spawn  tail     -f     dev null     stdio  ignore          var counter 0      setInterval function          console log  c       counter          1000        if  process platform slice 0 3      win           function killMeAndChildren                          On Linux Unix Include Mac OS X   kill  -pid  will kill process group  usually           the process itself and children            On Windows  an JOB object has been applied to current process and children            so all children will be terminated if current process dies by anyway                     console log  kill process group            process kill -process pid   SIGKILL                              When you use  kill pid of this process   this callback will be called                process on  SIGTERM   function err           console log  SIGTERM            killMeAndChildren                       By same way  you can install  exit  handler like above way if you call process exit somewhere  Note  Ctrl C and sudden crash have automatically been processed by OS to kill process group  so no more here   2 Use chjj pty js to spawn your process with controlling terminal attached  When you kill current process by anyway even kill -9  all child processes will be automatically killed too  by OS    I guess that because current process hold another side of the terminal  so if current process dies  the child process will get SIGPIPE so dies        var pty   require  pty js           var term       pty spawn  any child process      any arguments             name   xterm-color         cols  80        rows  30        cwd  process cwd          env  process env               optionally you can install data handler     term on  data   function data          process stdout write data               term write

User · Answer

If you re unable to modify the child process  you can try something like the following  int pipes 2   pipe pipes  if  fork      0        close pipes 1       Close the writer end in the child       dup2 pipes 0   STDIN FILENO      Use reader end as stdin  fixed per   maxschlepzig        exec  quot sh -c  set -o monitor  child process  amp  read dummy  kill  1  quot      close pipes 0       Close the reader end in the parent     This runs the child from within a shell process with job control enabled  The child process is spawned in the background  The shell waits for a newline  or an EOF  then kills the child  When the parent dies--no matter what the reason--it will close its end of the pipe  The child shell will get an EOF from the read and proceed to kill the backgrounded child process

User · Answer

Historically  from UNIX v7  the process system has detected orphanity of processes by checking a process  parent id   As I say  historically  the init 8  system process is a special process by only one reason  It cannot die   It cannot die because the kernel algorithm to deal with assigning a new parent process id  depends on this fact   when a process executes its exit 2  call  by means of a process system call or by external task as sending it a signal or the like  the kernel reassigns all children of this process the id of the init process as their parent process id   This leads to the most easy test  and most portable way of knowing if a process has got orphan   Just check the result of the getppid 2  system call and if it is the process id of the init 2  process then the process got orphan before the system call   Two issues emerge from this approach that can lead to issues    first  we have the possibility of changing the init process to any user process  so How can we assure that the init process will always be parent of all orphan processes  Well  in the exit system call code there s a explicit check to see if the process executing the call is the init process  the process with pid equal to 1  and if that s the case  the kernel panics  It should not be able anymore to maintain the process hierarchy  so it is not permitted for the init process to do an exit 2  call  second  there s a race condition in the basic test exposed above   Init process  id is assumed historically to be 1  but that s not warranted by the POSIX approach  that states  as exposed in other response  that only a system s process id is reserved for that purpose  Almost no posix implementation does this  and you can assume in original unix derived systems that having 1 as response of getppid 2  system call is enough to assume the process is orphan   Another way to check is to make a getppid 2  just after the fork and compare that value with the result of a new call   This simply doesn t work in all cases  as both call are not atomic together  and the parent process can die after the fork 2  and before the first getppid 2  system call   The processparent id only changes once  when its parent does anexit 2 call  so this should be enough to check if thegetppid 2 result changed between calls to see that parent process has exit   This test is not valid for the actual children of the init process  because they are always children ofinit 8    but you can assume safely these processes as having no parent either  except when you substitute in a system the init process

User · Answer

I don t believe it s possible to guarantee that using only standard POSIX calls   Like real life  once a child is spawned  it has a life of its own   It is possible  for the parent process to catch most possible termination events  and attempt to kill the child process at that point  but there s always some that can t be caught   For example  no process can catch a SIGKILL   When the kernel handles this signal it will kill the specified process with no notification to that process whatsoever   To extend the analogy - the only other standard way of doing it is for the child to commit suicide when it finds that it no longer has a parent   There is a Linux-only way of doing it with prctl 2  - see other answers

User · Answer

Under Linux  you can install a parent death signal in the child  e g     include  lt sys prctl h gt     prctl    PR SET PDEATHSIG  include  lt signal h gt     signals  include  lt unistd h gt     fork    include  lt stdio h gt      perror            pid t ppid before fork   getpid    pid t pid   fork    if  pid    -1    perror 0   exit 1     if  pid             continue parent execution   else       int r   prctl PR SET PDEATHSIG  SIGTERM       if  r    -1    perror 0   exit 1            test in case the original parent exited just        before the prctl   call     if  getppid      ppid before fork          exit 1          continue child execution       Note that storing the parent process id before the fork and testing it in the child after prctl   eliminates a race condition between prctl   and the exit of the process that called the child   Also note that the parent death signal of the child is cleared in newly created children of its own  It is not affected by an execve     That test can be simplified if we are certain that the system process who is in charge of adopting all orphans has PID 1   pid t pid   fork    if  pid    -1    perror 0   exit 1     if  pid             continue parent execution   else       int r   prctl PR SET PDEATHSIG  SIGTERM       if  r    -1    perror 0   exit 1            test in case the original parent exited just        before the prctl   call     if  getppid      1          exit 1          continue child execution       Relying on that system process being init and having PID 1 isn t portable  though  POSIX 1-2008 specifies      The parent process ID of all of the existing child processes and zombie processes of the calling process shall be set to the process ID of an implementation-defined system process  That is  these processes shall be inherited by a special system process    Traditionally  the system process adopting all orphans is PID 1  i e  init - which is the ancestor of all processes   On modern systems like Linux or FreeBSD another process might have that role  For example  on Linux  a process can call prctl PR SET CHILD SUBREAPER  1  to establish itself as system process that inherits all orphans of any of its descendants   cf  an example on Fedora 25

User · Answer

If you send a signal to the pid 0  using for instance  kill 0  2      SIGINT      that signal is sent to the entire process group  thus effectively killing the child   You can test it easily with something like    cat  amp  amp  kill 0    python   If you then press  D  you ll see the text  Terminated  as an indication that the Python interpreter have indeed been killed  instead of just exited because of stdin being closed

User · Answer

Install a trap handler to catch SIGINT  which kills off your child process if it s still alive  though other posters are correct that it won t catch SIGKILL    Open a  lockfile with exclusive access and have the child poll on it trying to open it - if the open succeeds  the child process should exit

User · Answer

Under Linux  you can install a parent death signal in the child  e g     include  lt sys prctl h gt     prctl    PR SET PDEATHSIG  include  lt signal h gt     signals  include  lt unistd h gt     fork    include  lt stdio h gt      perror            pid t ppid before fork   getpid    pid t pid   fork    if  pid    -1    perror 0   exit 1     if  pid             continue parent execution   else       int r   prctl PR SET PDEATHSIG  SIGTERM       if  r    -1    perror 0   exit 1            test in case the original parent exited just        before the prctl   call     if  getppid      ppid before fork          exit 1          continue child execution       Note that storing the parent process id before the fork and testing it in the child after prctl   eliminates a race condition between prctl   and the exit of the process that called the child   Also note that the parent death signal of the child is cleared in newly created children of its own  It is not affected by an execve     That test can be simplified if we are certain that the system process who is in charge of adopting all orphans has PID 1   pid t pid   fork    if  pid    -1    perror 0   exit 1     if  pid             continue parent execution   else       int r   prctl PR SET PDEATHSIG  SIGTERM       if  r    -1    perror 0   exit 1            test in case the original parent exited just        before the prctl   call     if  getppid      1          exit 1          continue child execution       Relying on that system process being init and having PID 1 isn t portable  though  POSIX 1-2008 specifies      The parent process ID of all of the existing child processes and zombie processes of the calling process shall be set to the process ID of an implementation-defined system process  That is  these processes shall be inherited by a special system process    Traditionally  the system process adopting all orphans is PID 1  i e  init - which is the ancestor of all processes   On modern systems like Linux or FreeBSD another process might have that role  For example  on Linux  a process can call prctl PR SET CHILD SUBREAPER  1  to establish itself as system process that inherits all orphans of any of its descendants   cf  an example on Fedora 25

User · Answer

This solution worked for me    Pass stdin pipe to child - you don t have to write any data into the stream  Child reads indefinitely from stdin until EOF  An EOF signals that the parent has gone  This is foolproof and portable way to detect when the parent has gone  Even if parent crashes  OS will close the pipe    This was for a worker-type process whose existence only made sense when the parent was alive

User · Answer

I have achieved this in the past by running the "original" code in the "child" and the "spawned" code in the "parent" (that is: you reverse the usual sense of the test after fork()). Then trap SIGCHLD in the "spawned" code...

May not be possible in your case, but cute when it works.

User · Answer

Another way to do this that is Linux specific is to have the parent be created in a new PID namespace  It will then be PID 1 in that namespace  and when it exits it all of it s children will be immediately killed with SIGKILL   Unfortunately  in order to create a new PID namespace you have to have CAP SYS ADMIN  But  this method is very effective and requires no real change to the parent or the children beyond the initial launch of the parent   See clone 2   pid namespaces 7   and unshare 2

User · Answer

I think a quick and dirty way is to create a pipe between child and parent  When parent exits  children will receive a SIGPIPE

User · Answer

Install a trap handler to catch SIGINT  which kills off your child process if it s still alive  though other posters are correct that it won t catch SIGKILL    Open a  lockfile with exclusive access and have the child poll on it trying to open it - if the open succeeds  the child process should exit

User · Answer

Does the child process have a pipe to from the parent process  If so  you d receive a SIGPIPE if writing  or get EOF when reading - these conditions could be detected

User · Answer

Does the child process have a pipe to from the parent process  If so  you d receive a SIGPIPE if writing  or get EOF when reading - these conditions could be detected

User · Answer

Install a trap handler to catch SIGINT  which kills off your child process if it s still alive  though other posters are correct that it won t catch SIGKILL    Open a  lockfile with exclusive access and have the child poll on it trying to open it - if the open succeeds  the child process should exit

User · Answer

If you re unable to modify the child process  you can try something like the following  int pipes 2   pipe pipes  if  fork      0        close pipes 1       Close the writer end in the child       dup2 pipes 0   STDIN FILENO      Use reader end as stdin  fixed per   maxschlepzig        exec  quot sh -c  set -o monitor  child process  amp  read dummy  kill  1  quot      close pipes 0       Close the reader end in the parent     This runs the child from within a shell process with job control enabled  The child process is spawned in the background  The shell waits for a newline  or an EOF  then kills the child  When the parent dies--no matter what the reason--it will close its end of the pipe  The child shell will get an EOF from the read and proceed to kill the backgrounded child process

User · Answer

I have achieved this in the past by running the "original" code in the "child" and the "spawned" code in the "parent" (that is: you reverse the usual sense of the test after fork()). Then trap SIGCHLD in the "spawned" code...

May not be possible in your case, but cute when it works.

User · Answer

Another way to do this that is Linux specific is to have the parent be created in a new PID namespace  It will then be PID 1 in that namespace  and when it exits it all of it s children will be immediately killed with SIGKILL   Unfortunately  in order to create a new PID namespace you have to have CAP SYS ADMIN  But  this method is very effective and requires no real change to the parent or the children beyond the initial launch of the parent   See clone 2   pid namespaces 7   and unshare 2

User · Answer

Even though 7 years have passed I ve just run into this issue as I m running SpringBoot application that needs to start webpack-dev-server during development and needs to kill it when the backend process stops   I try to use Runtime getRuntime   addShutdownHook but it worked on Windows 10 but not on Windows 7   I ve change it to use a dedicated thread that waits for the process to quit or for InterruptedException which seems to work correctly on both Windows versions   private void startWebpackDevServer         String cmd   isWindows      cmd  c gradlew webPackStart     gradlew webPackStart       logger info  webpack dev-server     cmd        Thread thread   new Thread    - gt             ProcessBuilder pb   new ProcessBuilder cmd split                pb redirectOutput ProcessBuilder Redirect INHERIT           pb redirectError ProcessBuilder Redirect INHERIT           pb directory new File                 Process process   null          try                  Start the node process             process   pb start                    Wait for the node process to quit  blocking              process waitFor                    Ensure the node process is killed             process destroyForcibly                System setProperty WEBPACK SERVER PROPERTY   true              catch  InterruptedException   IOException e                   Ensure the node process is killed                 InterruptedException is thrown when the main process exit              logger info  killing webpack dev-server   e               if  process    null                    process destroyForcibly                                          thread start

User · Answer

Child can ask kernel to deliver SIGHUP  or other signal  when parent dies by specifying option PR SET PDEATHSIG in prctl   syscall like this   prctl PR SET PDEATHSIG  SIGHUP    See man 2 prctl for details   Edit  This is Linux-only

User · Answer

Child can ask kernel to deliver SIGHUP  or other signal  when parent dies by specifying option PR SET PDEATHSIG in prctl   syscall like this   prctl PR SET PDEATHSIG  SIGHUP    See man 2 prctl for details   Edit  This is Linux-only

User · Answer

I managed to do a portable  non-polling solution with 3 processes by abusing terminal control and sessions  The trick is   process A is started process A creates a pipe P  and never reads from it  process A forks into process B process B creates a new session process B allocates a virtual terminal for that new session process B installs SIGCHLD handler to die when the child exits process B sets a SIGPIPE handler process B forks into process C process C does whatever it needs  e g  exec  s the unmodified binary or runs whatever logic  process B writes to pipe P  and blocks that way  process A wait  s on process B and exits when it dies  That way   if process A dies  process B gets a SIGPIPE and dies if process B dies  process A s wait   returns and dies  process C gets a SIGHUP  because when the session leader of a session with a terminal attached dies  all processes in the foreground process group get a SIGHUP  if process C dies  process B gets a SIGCHLD and dies  so process A dies  Shortcomings   process C can t handle SIGHUP process C will be run in a different session process C can t use session process group API because it ll break the brittle setup creating a terminal for every such operation is not the best idea ever

User · Answer

Under POSIX  the exit     exit   and  Exit   functions are defined to    If the process is a controlling process  the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process    So  if you arrange for the parent process to be a controlling process for its process group  the child should get a SIGHUP signal when the parent exits   I m not absolutely sure that happens when the parent crashes  but I think it does   Certainly  for the non-crash cases  it should work fine   Note that you may have to read quite a lot of fine print - including the Base Definitions  Definitions  section  as well as the System Services information for exit   and setsid   and setpgrp   - to get the complete picture    So would I

User · Answer

In case it is relevant to anyone else  when I spawn JVM instances in forked child processes from C    the only way I could get the JVM instances to terminate properly after the parent process completed was to do the following  Hopefully someone can provide feedback in the comments if this wasn t the best way to do this   1  Call prctl PR SET PDEATHSIG  SIGHUP  on the forked child process as suggested before launching the Java app via execv  and   2  Add a shutdown hook to the Java application that polls until its parent PID equals 1  then do a hard Runtime getRuntime   halt 0   The polling is done by launching a separate shell that runs the ps command  See  How do I find my PID in Java or JRuby on Linux     EDIT 130118   It seems that was not a robust solution  I m still struggling a bit to understand the nuances of what s going on  but I was still sometimes getting orphan JVM processes when running these applications in screen SSH sessions    Instead of polling for the PPID in the Java app  I simply had the shutdown hook perform cleanup followed by a hard halt as above  Then I made sure to invoke waitpid in the C   parent app on the spawned child process when it was time to terminate everything  This seems to be a more robust solution  as the child process ensures that it terminates  while the parent uses existing references to make sure that its children terminate  Compare this to the previous solution which had the parent process terminate whenever it pleased  and had the children try to figure out if they had been orphaned before terminating

User · Answer

I ve passed parent pid using environment to the child  then periodically checked if  proc  ppid exists from the child

User · Answer

If parent dies  PPID of orphans change to 1 - you only need to check your own PPID  In a way  this is polling  mentioned above  here is shell piece for that   check parent            parent  ps -f awk   2    PID  print  3           echo  parent  parent        let parent  parent 0       if     parent -eq 1     then         echo  parent is dead  exiting          exit        fi     PID    cnt 0 while    1   1     do   check parent       something done

[c] How to make child process die after parent exits?

Examples related to c

Examples related to linux

Examples related to unix

Examples related to process

Examples related to fork