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

[Mantas Mikulėnas]

On Wed, Feb 14, 2018 at 3:06 AM, Josh Snyder <joshs at netflix.com> wrote:

> Hi all,
>
> I'm working on a use-case where I want to impose memory limits on the
> system in
> aggregate, with one process (e.g. memcached) opted-out of the limit. With a
> typical distribution's setup (Ubuntu, in my case), I would be able to
> impose a
> memory limit on each systemd slice (viz. user, machine, system)
> separately, but
> not in aggregate.
>
> I've found a solution for this by launching systemd in a cgroup of its
> own. In
> the initramfs, I have a script (snippet included below) which mounts the
> cgroupfs, puts all of the extant processes into a new cgroup, and then
> umounts
> the cgroupfs.
>
> This works for my needs: all of the processes in the system live in one
> cgroup,
> except memcached in a separate cgroup. systemd seems perfectly happy to
> boot in
> this configuration, correctly sensing that it's operating in a cgroup and
> nesting the processes it is responsible for under the existing cgroup. With
> memcached running separately, the resulting hierarchy looks like:
>
> /sys/fs/cgroup/
> ├── memcached
> └── root
>     ├── init.scope
>     ├── system.slice
>     ...
>
> And /proc/1/cgroup shows that the systemd (and more importantly, its
> descendants) lives in the memory cgroup:
>
> 11:net_cls,net_prio:/
> 10:cpuset:/
> 9:freezer:/
> 8:hugetlb:/
> 7:perf_event:/
> 6:pids:/root/init.scope
> 5:devices:/root/init.scope
> 4:cpu,cpuacct:/
> 3:blkio:/
> 2:memory:/root
> 1:name=systemd:/root/init.scope
>
> 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?
>

I'm assuming it happens to work because the unprivileged `systemd --user`
instances require the same kind of autodetection.

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180214/8880e6c4/attachment.html>