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. ⠈⠳⣄⠀⠀⠀⠀ _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
