4 ms·

There is one very important distinction. If pgsql forks to handle connections, the PPID of the child processes points back to the "main" pgsql process, which i

There is one very important distinction. If pgsql forks to handle connections, the PPID of the child processes points back to the "main" pgsql process, which is still around. Whereas, traditionally, if a wannabe daemon forks and exits, the PPID of its now orphaned child reverts to 1.

zokier 2y ago
afaik you need cgroups if you want to accurately track a process tree regardless of what silly tricks the processes might be try to escape
- thwarted 2y ago
  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.
- thayne 2y ago
  And not even cgroups are enough if the process has write access to another cgroup (for example, because it is root)

zokier 2y ago

afaik you need cgroups if you want to accurately track a process tree regardless of what silly tricks the processes might be try to escape

thwarted 2y ago
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.
thayne 2y ago
And not even cgroups are enough if the process has write access to another cgroup (for example, because it is root)