Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Killing a process and all of its descendants

morningcoffee.io

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Killing a process and all of its descendants

#51

Post by lclarkmichalek »

hnarn wrote: post #27
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.

systemd uses cgroups, correct? just wondering what the options are for learning more about this, would it be enough, assuming you'd only be working with systemd operating systems, to learn the systemd concepts of slices etc.?

slices generally map 1:1 with cgroups. Try running systemd-cgtop and you can see the resource usage of each of the cgroups

Re: Killing a process and all of its descendants

#52

Post by mehrdadn »

pas wrote: post #26
mehrdadn wrote: post #7

Earlier quoted context omitted.

Wow, finally! Committed just 3 months ago. Might be able to finally rely on it in Linux distros a few years from now! https://github.com/torvalds/linux/commit/b53b0b9d9a613c41805...

It's in kernel v5.3, which is expected in September, so it might be in Ubuntu Eoan Ermine 19.10. (After all 5.0 got released in March and Ubuntu 19.04 ships with 5.0.)

Yeah, that's when you'll just start seeing the new kernel in the wild. Not when you'll stop seeing older kernels in the wild.

Re: Killing a process and all of its descendants

#53

Post by dataflow »

cyphar wrote: post #39
mehrdadn wrote: post #15

Earlier quoted context omitted.

Perhaps pidfd_open(pid, ...)? https://lwn.net/Articles/789023/ I find it bizarre they called it "pidfd_" rather than just "process_" or "proc_"... almost seems like they deliberately avoided the obvious?

It's because the object you get is a file descriptor. In fact it's exactly equivalent to getting a file descriptor for /proc/$pid -- Christian (the person who developed the patchsets) quite cleverly solidified a trick that some folks knew about for several years (that you could use /proc/$pid as a race-free way of checking if a process has died if you grabbed a handle while it was still alive). Before pidfd_send_sign…

> It's because the object you get is a file descriptor.

It is, but you're opening the object, not the descriptor (which doesn't even exist yet). When you open a kernel object, you always get back a (new) file descriptor representing that object. It's against previous naming conventions too. It's not like mkfifo() was called mkfifofd() or socket() was called socketfd() or perf_event_open() was called perf_event_fd_open()...

I'm really amused that you're so excited about it and find it so cool. I mean, I'm not suggesting it isn't awesome that they added it, but to me, it's such a glaring obvious deficiency that I'm completely flabbergasting that a lot of battles had to be fought to include it. It should've been added and embraced with open arms over two decades ago...

Re: Killing a process and all of its descendants

#54

Post by dataflow »

coldtea wrote: post #23
mehrdadn wrote: post #15

Earlier quoted context omitted.

Perhaps pidfd_open(pid, ...)? https://lwn.net/Articles/789023/ I find it bizarre they called it "pidfd_" rather than just "process_" or "proc_"... almost seems like they deliberately avoided the obvious?

What obvious? The command creates and returns a pidfd for the pid passed, not a process or a proc (which would be conflated with other concepts in Linux).

But you're opening the object (which already exists), not a file descriptor (which doesn't exist yet). And when you create or open a kernel object, you always get back a (new) file descriptor representing that object. See perf_event_open, mkfifo, etc. I'm not really sure how it'd have conflated with anything to call it proc_open or something like that, but I'll take your word on it.

Re: Killing a process and all of its descendants

#56

Post by hombre_fatal »

pas wrote: post #20
caspper69 wrote: post #12

Earlier quoted context omitted.

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.

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?"

Re: Killing a process and all of its descendants

#60

Post by cyphar »

dataflow wrote: post #53
cyphar wrote: post #39

Earlier quoted context omitted.

It's because the object you get is a file descriptor. In fact it's exactly equivalent to getting a file descriptor for /proc/$pid -- Christian (the person who developed the patchsets) quite cleverly solidified a trick that some folks knew about for several years (that you could use /proc/$pid as a race-free way of checking if a process has died if you grabbed a handle while it was still alive). Before pidfd_send_sign…

> It's because the object you get is a file descriptor. It is, but you're opening the object, not the descriptor (which doesn't even exist yet). When you open a kernel object, you always get back a (new) file descriptor representing that object. It's against previous naming conventions too. It's not like mkfifo() was called mkfifofd() or socket() was called socketfd() or perf_event_open() was called perf_event_fd_ope…

> It is, but you're opening the object, not the descriptor (which doesn't even exist yet).

pidfd_open(2) is still a proposed interface, and isn't in mainline yet (and if I'm remembering the ML discussions correctly, it might not even go in any time soon). The currently-available interfaces are pidfd_send_signal(2), CLONE_PIDFD, and the new pidfd_poll(2) support for pidfds. In that context, calling it "pidfd_" makes more sense (since you're operating on existing handles) and thus pidfd_open(2) also makes sense because otherwise the naming would be needlessly inconsistent.

There are also several pre-existing APIs that are called process_ (such as process_vm_{read,write}v(2)) which use pids and not pidfds -- so calling the new APIs process_ (or even proc_) could lead to confusion. From memory the first couple of iterations of the patchset changed the name several times until we landed on pidfd_ and nobody really complained much afterwards.

Also (and now I'm just nitpicking), mkfifo(3) doesn't give you an fd -- it's just a wrapper around mknod(2). But I do get your point.

> I'm really amused that you're so excited about it and find it so cool.

I might be a little bit more biased towards thinking it's cool, since the developer is a good friend of mine and we went back and forth on the design quite a lot (the fact he managed to get /proc/$pid fds to have these features is pretty remarkable and it's unbelievably cool that it didn't require having multiple classes of fds -- if you'd have asked me a year ago I would've said it'd be very hard to get right and would never be merged because it'd be so invasive). But thinking that it's neat isn't mutually exclusive with thinking that (something like) it should've been implemented a long time ago.

Post reply on HN