If you really want systemd to add this then I'm sure they will look at your feature request or PR.
I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error. In my experience BSD-based Unixes get it right and don't use procfs for ps or pkill. They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps. Linux also still does. Try unmounting proc and running ps or kill and see what happens. If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill(). POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned.
There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill. This can happen on any Unix and is not some big mystery either. PID reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal. There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.
>If you really want systemd to add this then I'm sure they will look at your feature request or PR.
The less systems touches the better.
>I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error.
Who said this was bash? The script from all those years ago worked perfectly without race conditions.
>They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps.
Makes no difference, procfs works fine for this.
>Try unmounting proc and running ps or kill and see what happens.
You're effectively never unmounting procfs. Also, if you managed to, systemd would crash!
>If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill().
There's maybe 10 lines of code to ensure that logic. Again, middling sysadmin work.
>POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned.
POSIX does say something about this; read about signals. You stop the process before killing it, and ensure that the start time is the same for the stopped process before the kill. That completely eliminates the race condition, using basic POSIX signals.
>There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill.
That race condition is eliminated with the logic above. That eliminates the PID reuse race condition, even if it's very rare.
>reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal.
That functionality is where it belongs now, so instead of coding a logic every time you have to ensure PIDs, it's now handled for you.
>There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.
Correct, I don't want to hear it from someone who doesn't understand POSIX and basic/intermediate sysadmin work.
I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error. In my experience BSD-based Unixes get it right and don't use procfs for ps or pkill. They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps. Linux also still does. Try unmounting proc and running ps or kill and see what happens. If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill(). POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned.
There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill. This can happen on any Unix and is not some big mystery either. PID reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal. There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.