<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 14, 2018 at 3:06 AM, Josh Snyder <span dir="ltr"><<a href="mailto:joshs@netflix.com" target="_blank">joshs@netflix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'm working on a use-case where I want to impose memory limits on the system in<br>
aggregate, with one process (e.g. memcached) opted-out of the limit. With a<br>
typical distribution's setup (Ubuntu, in my case), I would be able to impose a<br>
memory limit on each systemd slice (viz. user, machine, system) separately, but<br>
not in aggregate.<br>
<br>
I've found a solution for this by launching systemd in a cgroup of its own. In<br>
the initramfs, I have a script (snippet included below) which mounts the<br>
cgroupfs, puts all of the extant processes into a new cgroup, and then umounts<br>
the cgroupfs.<br>
<br>
This works for my needs: all of the processes in the system live in one cgroup,<br>
except memcached in a separate cgroup. systemd seems perfectly happy to boot in<br>
this configuration, correctly sensing that it's operating in a cgroup and<br>
nesting the processes it is responsible for under the existing cgroup. With<br>
memcached running separately, the resulting hierarchy looks like:<br>
<br>
/sys/fs/cgroup/<br>
├── memcached<br>
└── root<br>
    ├── init.scope<br>
    ├── system.slice<br>
    ...<br>
<br>
And /proc/1/cgroup shows that the systemd (and more importantly, its<br>
descendants) lives in the memory cgroup:<br>
<br>
11:net_cls,net_prio:/<br>
10:cpuset:/<br>
9:freezer:/<br>
8:hugetlb:/<br>
7:perf_event:/<br>
6:pids:/root/init.scope<br>
5:devices:/root/init.scope<br>
4:cpu,cpuacct:/<br>
3:blkio:/<br>
2:memory:/root<br>
1:name=systemd:/root/init.<wbr>scope<br>
<br>
I've tested against both legacy and unified cgroup hierarchies. The<br>
functionality to detect the current cgroups and nest processes underneath them<br>
appears to be in manager_setup_cgroup (src/core/cgroup.c:2033). My question for<br>
the list is what motivated adding this awesome feature to systemd in the first<br>
place, and (more importantly to me) is it likely to continue to exist in the<br>
future?<br></blockquote><div><br></div><div>I'm assuming it happens to work because the unprivileged `systemd --user` instances require the same kind of autodetection.</div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div>
</div></div>