GitLab

From the man page:

       PR_SET_PDEATHSIG (since Linux 2.1.57)
              Set  the  parent  process death signal of the calling process to
              arg2 (either a signal value in the  range  1..maxsig,  or  0  to
              clear).   This  is  the signal that the calling process will get
              when its parent dies.  This value is cleared for the child of  a
              fork(2)  and (since Linux 2.4.36 / 2.6.23) when executing a set-
              user-ID or set-group-ID binary, or a binary that has  associated
              capabilities  (see  capabilities(7)).   This  value is preserved
              across execve(2).

This will ensure at least on Linux that all background processes will get a SIGTERM if Tor dies, and can cleanup appropriately.

I don't think this behavior would be particularly shocking to PT developers (who should be handling SIGTERM already), so this probably doesn't even need a spec patch since "tor dying" invoking the normal termination signaling is appropriate.

The choice of SIGTERM over SIGKILL here is so that PTs have the option to trap it and terminate their own children as appropriate.

Pros:

• Easy to do.
• The kernel does all of the heavy lifting for us, as a catchall.
• Fixes certain nasty issues in unmodified pt code on the relevant platform automatically.

Cons:

• Non-portable (#15435 (moved) aka #10047 (moved) is a portable fix that requires pt modification).
• We have pts (obfs4proxy in particular) that can be ran with elevated capabilities.