3 ms·

There is quite a few fun bugs you can have. HTOP can race when it reads the process PID and then tries to kill it. If in the meantime, that process dies and a n

by zaarn 7y ago

There is quite a few fun bugs you can have. HTOP can race when it reads the process PID and then tries to kill it. If in the meantime, that process dies and a new process gets it's PID, then HTOP will kill the wrong process. There is procfd's nowadays that let you have a consistent handle on a specific process, but it doesn't solve the problem for anything that looks at PIDs. It also naturally limits you to hosting only 32K processes; my browser at work consumes almost 1000 PIDs mainly via a lot of threads running at the same time. At home where I have even more tabs open, it's likely that it is getting close to 5000 threads running. Of those 32K processes, only 27k remain, which is a significant chunk. I believe PID is a bit of a dated way to refer to processes and ultimately we should move to opaque process handles (like procfd).

im3w1l 7y ago
Do all syscalls that take a pid have a procfd equivalent?
- zbentley 7y ago
  No.
JdeBP 7y ago
Like the procdesc system on FreeBSD, which has some rather unfortunate semantics though. (Closing last open descriptors kills processes, by default.) One could make a collection of bugs that are revealed by (quite normal) process ID re-use. One of particular note in this context is the bug that occurs when one is using Linux control groups in lieu of proper job objects (which Linux does not have) and trying to do what on an actual first-class job object would be a "terminate all processes in this job" system call. * http://jdebp.uk./FGA/linux-control-groups-are-not-jobs.html http://jdebp.uk./FGA/linux-control-groups-are-not-jobs.html * https://github.com/systemd/systemd/issues/6803 https://github.com/systemd/systemd/issues/6803