[systemd-devel] running systemd in a cgroup: future compatibility

[Lennart Poettering]

On Di, 13.02.18 17:06, Josh Snyder (joshs at netflix.com) wrote:

> I've tested against both legacy and unified cgroup hierarchies. The
> functionality to detect the current cgroups and nest processes underneath them
> appears to be in manager_setup_cgroup (src/core/cgroup.c:2033). My question for
> the list is what motivated adding this awesome feature to systemd in the first
> place, and (more importantly to me) is it likely to continue to exist in the
> future?

This logic exists for two reasons:

1. "systemd --user" needs this so that it can manage the cgroup
   subtree it is started in. It gets a delegated, unprivileged cgroup
   subtree and couldn't even run outside of its subtree, even if it
   wanted to.

2. Before cgroup namespaces existed this kind of behaviour was
   necessary to make sure systemd run inside containers works
   correctly: it would only make use of its subtree, and leave alone
   the rest.

And besides that, cgroups is supposed to be neatly composable, hence
it's philosophically really the right thing to do. And yes, we'll
continue to support that.

That all said, I think we should really try to make systemd work with
your usecase directly and natively, i.e. add enough flexibility to
systemd so that you don't have to wrap it in such a "foreign" prefix
cgroup to do what you want... For example, if PID 1 knew a
"DefaultSlice=" option in /etc/systemd/system.conf, and
logind/machined knew similar options in their respective configuration
files you could do what you are trying to do without leaving systemd
territory relatively easily. Just set those options to some slice
further down thre tree, and you could leave machined run inside of
systemd just fine without having to arrange anything outside of it...

Lennart

-- 
Lennart Poettering, Red Hat