I'd like to introduce a solution for the problem originally described here:

pkill is not an atomic operation, not by a long stretch. In the while since pkill -P 666 foo has determined that pid 667 is the child of 666 named foo (which on e.g. Linux it does by opening and reading multiple files in the /proc fs) until it actually calls the kill(2) system call, the process could've already terminated and its pid could've been already reused.

In order to make pkill -P XXX operation safe (like transactions in SQL) I'd like to implement the Two Phase Commit Protocol:

  • Check if the process is child of THE_PARENT process.
  • If "yes", mark the PID of the child process as "DO_NOT_REUSE".
  • Check if the process is still the child of THE_PARENT process.
  • If "yes", kill the child process, if still possible.
  • Remove the DO_NOT_USE flag for that PID number.

For that purpose, can I mark a PID number as "can not be used"?

  • How would you avoid a race after the DO_NOT_USE removal? Sep 21, 2020 at 16:17
  • 2
    There are provisions in preparation to avoid races. Userland tools will have to follow somehow I guess: Adding the pidfd abstraction to the kernel, (and related spinoffs: Grabbing file descriptors with pidfd_getfd())
    – A.B
    Sep 21, 2020 at 16:39
  • @StephenKitt I don't understand how there will be a race state after the DO_NOT_USE removal. OS will just use that PID as usual. What is the point I may be missing?
    – ceremcem
    Sep 22, 2020 at 7:47
  • I thought I’d found a racing scenario but nothing I can think of now causes any issue (assuming this is implemented with the help of the kernel). Sep 22, 2020 at 8:03

1 Answer 1


The kernel will not reuse a pid until it 'wraps around'.

You can check the pid_max with cat /proc/sys/kernel/pid_max (4194304 on my system).

So it is very unlikely to reuse a pid in the time it takes to kill the process.

   /proc/sys/kernel/pid_max (since Linux 2.5.34)
       This file specifies the value at which PIDs wrap around (i.e.,
       the value in this file is one greater than the maximum PID).
       PIDs greater than this value are not allocated; thus, the
       value in this file also acts as a system-wide limit on the
       total number of processes and threads.  The default value for
       this file, 32768, results in the same range of PIDs as on ear‐
       lier kernels.  On 32-bit platforms, 32768 is the maximum value
       for pid_max.  On 64-bit systems, pid_max can be set to any
       value up to 2^22 (PID_MAX_LIMIT, approximately 4 million).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.