On Wed, Feb 14, 2018 at 1:38 AM, Lennart Poettering
wrote:
>
> 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 w
On Di, 13.02.18 17:06, Josh Snyder (jo...@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
On Wed, Feb 14, 2018 at 3:06 AM, Josh Snyder 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
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,