LWN: Comments on "Control groups, part 1: On the history of process grouping"

Control groups, part 1: On the history of process grouping

roblucid — Sat, 12 Jul 2014 19:27:30 +0000

It just means, that because processes other than pid 1, may exit, their forked children can escape, so a wait for children won't see them.

Say pid 20, forks many children, one pid 30 which starts a daemon pid 31, then pid 30 exits. Now the daemon has "escaped" the "children of process 30" group.. aren't inherited by 20, but when they exit can only be reaped by pid 1.

Funnily enough, I used Version 6 UNIX on a PDP11 and I do remember being confused once by signals delivered on my terminal, shortly after logging in on one occasion. Having received the explanation, I was doing a ps, for a while & choosing the "cool" seats, rather than deal with a repetition.

Control groups, part 1: On the history of process grouping

sflintham — Sat, 12 Jul 2014 16:11:56 +0000

The article says "In V6 Unix, the descendants of PID 1 (that set with a unity ID number) cannot escape but descendants of any other process can." But isn't every process a descendant of PID 1, in which case no process can ever escape? What am I missing here?

Control groups, part 1: On the history of process grouping

nix — Wed, 09 Jul 2014 21:45:03 +0000

Fabulous article: brings back memories of my first reading of Stevens's APUE: the intertwingled chapters on job control, signals and pgrps were memorable, in a terrifying way. I remember wishing it were possible to throw all this insane overcomplexity overboard and implement *one* mechanism to do all this.

Alas, back-compatibility being what it is, we are lumbered with this legacy horror show forever.

broken ps syntax

HelloWorld — Fri, 04 Jul 2014 10:32:10 +0000

They haven't, ps -aux is somewhat common yet it breaks when there's a user named x.

Control groups, part 1: On the history of process grouping

josh — Thu, 03 Jul 2014 20:57:17 +0000

It wouldn't necessarily make the TTY layer less fragile (although as a userspace framework it'd be easier to test and keep stable). It would, however, help make the kernel less fragile. TTY is one of the touchiest bits of the kernel, where what looks like a minor cleanup can break behavior that a 15-year-old version of emacs depends on.

The kernel could provide raw-mode-only serial ports (a pure bytestream only), and allow the userspace TTY framework to provide any additional "cooked" functionality of ttyS* or ttyUSB* on top of that, analogous to how the kernel would not need need to provide tty[1-9]*.

Control groups, part 1: On the history of process grouping

jpfrancois — Thu, 03 Jul 2014 15:10:46 +0000

And how would that make the tty layer less fragile ?
How would serial port be handled ? How would the serial driver be accessed from the cuse driver ?

Control groups, part 1: On the history of process grouping

sdalley — Thu, 03 Jul 2014 08:59:58 +0000

Thank you Neil Brown for your efforts to bring a cool overview with historical perspectives into this new and rapidly developing area. A great counterweight to some of the noisier and more opinionated comments that seem to follow anything associated with changes perceived as rocking the UNIX boat.

More light and less heat is great!

broken ps syntax

felixfix — Thu, 03 Jul 2014 06:34:26 +0000

Well, not to get into linguistic prescriptivist wars ... but if the options have worked for years in the face of warnings, it seems it is not nonsense in any practical sense.

Control groups, part 1: On the history of process grouping

deepfire — Wed, 02 Jul 2014 17:06:56 +0000

How does your reply make sense in the context, where the OP suggests _replacing_ a kernel part with a userspace part?

Control groups, part 1: On the history of process grouping

josh — Wed, 02 Jul 2014 16:31:13 +0000

Only if you use the built-in PTY driver, which is part of the TTY system. I'm suggesting moving the complex and fragile TTY layer out of the kernel into userspace.

broken ps syntax

HelloWorld — Wed, 02 Jul 2014 13:33:34 +0000

There are two sensible ways to operate ps, BSD-style:

ps axo 'comm,sess,pgrp'
# g flag is obsolete

or POSIX-style:

ps -eo 'comm,sess,pgrp'

But ps -axgo 'comm,sess,pgrp' is nonsense, and ps has been warning about this for years.

Control groups, part 1: On the history of process grouping

smurf — Wed, 02 Jul 2014 06:20:17 +0000

The PTY driver does that already, no need for CUSE.

You can build a kernel without VTs and use "screen" for multiplexing if you want to.

Control groups, part 1: On the history of process grouping

josh — Tue, 01 Jul 2014 20:45:44 +0000

Given the move to replace built-in VTs with userspace functionality, I wonder how much of an overhaul it would take to replace built-in TTYs as well? A TTY effectively seems like a pipe with an associated standard control channel (for things like "stop echoing"). The control channel could be emulated in userspace with a CUSE-based compatibility layer. The "controlling TTY" concept could be replaced by cgroup-based job control, handled by the shell or the process providing the equivalent of a VT.