4 ms·

Or prctl and PR_SET_CHILD_SUBREAPER are potentially useful for that.

• kazinator 2y ago
  So, all-round agreement that you need Linux extensions to fix legacy Unix situations that can be avoided by not forking grandchildren and using pidfiles and whatnot.
  • thwarted 2y ago
    Yes, as time goes on, new features are added, and some are meant to address deficiencies that were unanticipated at the time and the limitations of the earlier designs are discovered.
• thayne 2y ago
  How does that help? Setting that on the init process is pointless, since init already has the reaping behavior, and it when a process is reparented it doesn't give init any information about what the parent was when it is reparented. Setting it on the service process isn't helpful either, since the fored process will get reparented to init after the forking process dies since a dead process can't reap it.
  • kbolino 2y ago
    With subreaping as the only additional mechanism available, init would have to fork itself first and then keep that child running until all its descendants are done. Basically, every service would have a supervisor process (controlled by init) which roots a tree of all its other processes.
  • thwarted 2y ago
    Setting a process as the reaper means descendent processes are reparented to the reaper, which has to call wait like pid 1 does in order to collect the process's info and remove the zombie. This changes the default behavior where they are reparented to pid 1. You don't set this on pid 1 because, as you point out, pid 1 is already the reaper of last resort. You don't set this on the service process either; it is set on a process manager that isn't pid 1, so that process can monitor and collect info about its subtree of processes.