I feel a bit nerd sniped: On Linux PIDs are only unique within a PID namespace. But that doesn't matter because the entire point of a PID namespace is to isolate processes.
But it's worth mentioning because it can mitigate the problem you've laid out. If you have a long running process that may need to kill its children, you can start with within a new PID namespace such that it may only kill its children (or descendant).
This doesn't entirely solve the problem of potentially killing the wrong process though
No but it is a lot less likely for a PID to get reused on accident within a new PID namespace.
It's really no less likely, namespace or not. There are better mechanisms for handling this situation, pidfds for example.
That should only be a problem if you're running as root. Running as a dedicated user is also a mitigation.
Linux introduced pidfds for this reason.
Author here. Thanks for the feedback! Corrected the error.
Also note that openbsd uses random pids.
And FreeBSD if so configured:
$ sysctl kern.pid_max kern.randompid
kern.pid_max: 99999
kern.randompid: 594
This isn't true. The pid increments most of the time, but occasionally the new pid jumps down to a seemingly arbitrary value to start a new range. It is switching between unused ranges. This happens on my Linux machines all the time.
However, it doesn't matter for what the article describes: it doesn't depend on the pid always increasing, it only depends on the pid for each process being unique.
Pid reuse doesn't matter often, but it matters occasionally with how sigals are often used. Many scripts are written to signal a process that might have terminated already, e.g. using a pid stored in an environment variable or file. This usually just returns an error, but if there has been enough system activity meanwhile, the pid may belong to a new process, which the script does not intend to signal, so a random process may be killed unexpectedly.