systemd for 11.10 ?

Serge Hallyn serge.hallyn at canonical.com
Fri May 13 11:47:07 UTC 2011


Quoting Patrick Goetz (pgoetz at mail.utexas.edu):
> On 05/12/2011 07:00 AM, ubuntu-devel-request at lists.ubuntu.com wrote:
> >From: Steve Langasek <steve.langasek at ubuntu.com>
> >Date: Thu, 12 May 2011 11:40:12 +0200
> >
> 
> >That's what happens*today*.  But cgroups are an entirely new interface in
> >the kernel that in systemd explicitly prevents that from happening.
> 
> "Any process (task) on the system which forks itself creates a child
> process (task). The child task automatically becomes members of all
> of the cgroups its parent is members of. The child task can then be
> moved to different cgroups as needed, but initially, it always
> inherits the cgroups (the "environment" in process terminology) of
> its parent task.
> 
> From that point forward, the parent and child tasks are completely
> independent of each other: changing the cgroups that one task
> belongs to does not affect the other. Neither will changing cgroups
> of a parent task affect any of its grandchildren in any way. To
> summarize: any child task always initially inherit memberships to
> the exact same cgroups as their parent task, but those memberships
> can be changed or removed later."
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Relationships_Between_Subsystems_Hierarchies_Control_Groups_and_Tasks.html
> 
> 
> Sounds like this is just a matter of screen being updated to be
> cgroup-aware.

Not even.  Another task can do it, or you can do it by hand when or
after you start your screeen session.

But again, that's also why cgroups are not the panacea "preventing
userspace from escaping a kill for change to runlevel 1".  What they
are is a convenient kernel mechanism for helping to track (and
constrain) tasks.

-serge



More information about the ubuntu-devel mailing list