This is a (rare?) instance where I would say Win32 gives you some remedy over POSIX. On Windows, you can open a handle and deal with that, rather than a pid. Once the handle is open, it isn't subject to this recycling problem.

However if opening a handle based on pid you may want to double-check that the handle matches your expectation before using it, since that would be prone to the same race.

This is actually what pidfd does on linux, you get a handle to the process that lets you interact with it in that same manner. Once the process exits the handle gets closed and all the operations will report an error even if you have a recycled pid

Not that it matters much these days, but do note that pidfd is a Linux concept, not a posix one. It's also a fairly recent one and it'll be a number of years before many people can use it even still. Windows by comparison has had a solution for white some time.

I dont care much for Windows, but I would argue that it's well architected compared to nix in many regards.

The classic ABA problem, then.

https://en.wikipedia.org/wiki/ABA_problem

Had no idea about this! Thank you. Now I'm starting to understand undefined behavior safety is such a walled garden. All sorts of snakes might be lurking beneath.

I've always felt like it should be the case that as long as a pidfd for that process is open, the pid doesn't get recycled, so you could open the pidfd and then use kill safely, then close it later. Means you wouldn't need a whole bunch of new syscalls.

Unfortunately, it seems like this idea was rejected during the introduction of pidfd.

I think the idea with that was it would lead to denial-of-service type situations where some process could leak a bunch of pidfds and then that would cause exhaustion of pids everywhere else.

A process could also do that by spawning a bunch of processes if it wanted to.

Not really, most systems should set RLIMIT_NPROC to prevent that. If pidfds held onto the pid, it would create a new denial-of-service that allowed random other processes to keep zombie processes open, and the fix for it would actually allow you to circumvent that limit!

Isn't this easily fixed by counting held processes via pidfd towards RLIMIT_NPROC? You'd get a rlimit error when calling pidfd_open, but it already returns EMFILE for RLIMIT_NOFILE, so that doesn't seem onerous unless you're trying to enforce exact numbers of processes rather than "less than some reasonable limit".

Edit: note that pidfds holding same-uid processes have no effect (that process already belongs to your uid), and multiple processes holding a single foreign process only count once (that single foreign process is counted toward your NPROC, since it will stick around for pidfd even if its user kills it).

You can also set RLIMIT_NOFILE to prevent the number of FDs the app can open if you're worried about it.

I don't think that would necessary solve it, since the maximum number you can have open is still RLIMIT_NPROC * RLIMIT_NOFILE, right? It seems it would still be a problem as long as it's greater than RLIMIT_NPROC. Edit: I suppose you could fix it as long as you could guarantee that NPROC * NOFILE * maxlogins < kernel.pid_max... but to me this is piling on more workarounds.

This might be naive of me, but isn't this in a way fixed by systemd service handling? Assuming the process in question is, in fact, handled as a service of course.

The issue is solved in any service manager as long as the service doesn't fork, when you are the parent process you can ensure that you don't reap the child before sending a signal.

Once the service forks then it becomes a problem. If you use cgroups it can be solved separately with the cgroup freezer, but there are still some open issues with this in systemd: https://github.com/systemd/systemd/issues/13101

Correct.