Killing a process and all of its descendants • Hacker News Board

Re: Killing a process and all of its descendants

#71

Post by jchw » Sun, Aug 04, 2019, 7:02 PM UTC

neerajsi wrote: post #70

jchw wrote: post #38

Bazel-watcher tries to accomplish this on Linux by using process group IDs. It works, if imperfectly sometimes. I ported this to Windows[1] using Job Objects. As usual, the Windows API was hell, and I made use of undocumented syscalls in order to make it work (though that part is partly Go’s fault: when you start a process, it immediately drops the thread handle on the floor. If you start a process suspended, that me…

I'm confused by this post, but I'm an ex-dev on the NT kernel. ResumeThread is a well documented API. As is TerminateJobObject. The one thing I find a bit baroque is the recently added way to make sure a process is in a job on creation, which I believe is part is the ProcThreadAttributes mechanism.

Yes, ResumeThread is. NtResumeProcess is what I had to use, because Go immediately closes the thread handle.

I’m sure it’s safe to rely on NtResumeProcess. I have used it since XP without issue. But I definitely wish there was a better way to go back from a process to a thread. The best I could find is using Toolhelp32 to iterate all the threads on the system, which I believe is just wrapping NtQuerySystemInformation. Would’ve worked but definitely wasn’t fast.

Re: Killing a process and all of its descendants

#72

Post by rkeene2 » Sun, Aug 04, 2019, 7:51 PM UTC

rlpb wrote: post #3

This is why cgroups were invented. They solve this problem. Start a process in its own cgroup, and you can later confidently kill the process and all of its descendants. Container "technologies" use cgroups extensively, as does systemd service management.

Exactly. Solaris implemented this as "contracts" to make its service management framework (SMF, which is similar to systemd, but came out first and is superior in many ways).

Re: Killing a process and all of its descendants

#73

Post by Dylan16807 » Mon, Aug 05, 2019, 3:18 AM UTC

stephen82 wrote: post #61

srathi wrote: post #57

Sometimes I wonder if I'm on a list somewhere for frequent Google searches such as this one - "How to kill a parent with all the children"!

Personally I use `killall` command and works as expected, at least on Debian. For instance, when I want to stop conky, all I do is run `killall conky` and kills all of its processes at once. Another longer way to do such thing is to run `kill -9 $(pidof conky)` which kills all returned processes.

Just be careful around Solaris!

Re: Killing a process and all of its descendants

#74

Post by kasabali » Wed, Aug 07, 2019, 10:33 PM UTC

caspper69 wrote: post #12

mehrdadn wrote: post #10

Earlier quoted context omitted.

Posted 1 week ago! Do you know what took them so long to realize this is the correct way to do it? Windows has had it for some two decades...

Unfortunately, as Linux has matured, many of its developers refuse to adapt technologies for the sole reason that it "stinks" of Microsoft. Cutler and his team were pretty forward thinking given that NT is over 30 years old. See also: the async i/o headaches and the inability to WaitForSingleObject()/WaitForMultipleObjects() (or an analogue) in Linux. It's a shame really.

> many of its developers refuse to adapt technologies for the sole reason that it "stinks" of Microsoft.

I don't where did you get that idea but it is not true at all. Linux developers have a history of ignoring (and reinventing) technologies and interfaces developed in other Unix systems, too. You can listen any Bryan Cantrill rant for more details. The claim that they refuse to adapt technologies that "stink" Microsoft is a mischaracterization.

Re: Killing a process and all of its descendants

#75

Post by pas » Fri, Aug 09, 2019, 10:40 PM UTC

hombre_fatal wrote: post #56

pas wrote: post #20

Earlier quoted context omitted.

re: WaitForMultipleObjects, finally something like that is likely coming to Linux: https://www.reddit.com/r/linux/comments/ck77gm/valve_propose... > It's a shame really. Well, yes, and of course, yet at the same time it's FOSS, so ... if someone really needed it, they should have proposed a patch. ¯\_(ツ)_/¯

Things don't get accepted into mainline just because you did the work. This is a weird misconception people have about open source. You also see it when people ask "why did you build this instead of just contributing it to $largeProject?"

Huh. I never said it'll be magically accepted.

But you also can't say that it's somehow impossible to get anything other than what Linus et al. think is the very epitome of perfect.

Upstreaming stuff is an effort. Contributing to such a complex and fragile pile of code/crap/C must be done through the kernel devs.

But if you want to add a new FS, I/O scheduler, bytecode VM, or whatever, it's possible. Look at Ceph, btrfs, bcachefs, all the SSD/NAND oriented FS-es, look at eBPF, and the XDP [eXpress Data Path] IO Visor network thingie, or WireGuard [which is still not merged as far as I know, because it tried to bring its own crypto library instead of using the already existing stuff]. All the stuff getting upstreamed from Android piece by piece.

A lot of kernel devs are happy about this or that, but they are pragmatists.

And Linus doesn't veto big ideas just because, but does not want to pull sub-par implementations. (See KDBUS for example.)

Re: Killing a process and all of its descendants

#76

Post by pas » Fri, Aug 09, 2019, 10:40 PM UTC

caspper69 wrote: post #47

pas wrote: post #20

Earlier quoted context omitted.

re: WaitForMultipleObjects, finally something like that is likely coming to Linux: https://www.reddit.com/r/linux/comments/ck77gm/valve_propose... > It's a shame really. Well, yes, and of course, yet at the same time it's FOSS, so ... if someone really needed it, they should have proposed a patch. ¯\_(ツ)_/¯

RHEL had an entire async i/o subsystem. It was rejected upstream.

Could you provide some details about this?