Hacker News new | past | comments | ask | show | jobs | submit login

For example to kill all of the children of a process you first have to read all of the files in `/proc` to build a process tree, and then send your signals, by which time the process tree may have changed.



Yeah, as far as I know the only way to be sure is by putting the parent process into a cgroup. Then to kill all of the child processes you have to freeze the cgroup, enumerate the pids, send sigterm/sigkill to all of them, before unfreezing again.


Doesn't the new pidfd API you linked give you a race-free way to do that?


Maybe. Tbh I was trying to do something like that on RHEL8 and I think it's too old for procfd.


As long as you aren't trying to reimplement `systemd` badly, you really shouldn't have to deal with this.


"As long as you aren't trying to use the flawed API you won't run into any of its flaws."

Ok then.


More like "if you empty a safe-deposit box that doesn't belong to you, don't be surprised if random people start complaining about their goods being stolen."

Ownership matters for more than just memory. And the "just use GC" answer means deadlocks and leaks galore. If you limit yourself to killing processes you own, you will never have a problem.


So "you're holding it wrong" then? I don't get why you wouldn't want to have a reliable well-designed API for process management?


We already have one. What we don't have is an API for process pillaging.

Think about it - if you aren't init, what exactly is too limiting about "kill the processes or process groups of the children you created yourself"? As a rule, most grandchildren won't bother to enter a new process group, and if they do their immediate parent should be advanced enough to take responsibility for forwarding fatal signals.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: