On Tue, Aug 08, 2017 at 11:53:56AM -0400, Steve Litt wrote:
> Be careful recommending cgroups.
>
> I've never used them, and know little about them, but I know they were
> one of the main excuses for systemd.

Uhm, what? Systemd uses ELF objects too, should we go with a.out for this
reason?

cgroups are a way to say "this group of processes may not use more than 2GB
memory". How else would you ensure a misbehaving set of daemons / container
/etc does not bring down the rest of the system with it?

Then, you can set a lower limit to a subgroup of _those_ processes, in a
hierarchical way.

There are cgroup limits for a lot of resources. Try for example tc cgroup
that allows you set HTB classes, so a lxc virtual server belonging to one
client can't bandwidth-drown the rest, yet receives all unused bandwidth
when there's no contention.

Same for CPU use, I/O, etc, etc.


Systemd usurps to be the only user of this facility, but if you don't suffer
from systemd infestation, nothing keeps you from doing so yourself. In
fact, it works far better without systemd: unless it was fixed while I
wasn't looking, because of the way systemd sets it up, you can't use cgroups
in a container unless that container's systemd talks to the host's systemd
-- which is fragile, requires that both are infested, that both use a
compatible version, and using a different distribution or architecture makes
it no go. I for one run a bunch of amd64, i386 and x32 containers that
range from wheezy to unstable, and all is fine. Ok, I guess I'd have
problems running systemd inside, but I can accept _this_ retriction.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ James Damore is a hero. Even mild criticism of bigots these days
⢿⡄⠘⠷⠚⠋⠀ comes at great personal risk.
⠈⠳⣄⠀⠀⠀⠀