Jaromil - 09.08.17, 09:16: > On Tue, 08 Aug 2017, Martin Steigerwald wrote: > > Adam Borowski - 08.08.17, 18:57: > > > 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? > > > > I agree that cgroups can be a useful feature. Yet… also a bit clumsy to > > use, and not free of race conditions. That written, kernel developers are > > working to fix part of the clumsyness and completely and all of the race > > conditions by unifying all cgroup controllers (memory, cpu and so on) in > > one directory tree. > is the sourcecode of systemd the *only* example implementation of an > INIT 1 daemon using cgroups right now? > > here I see a lot of Go code > https://github.com/search?utf8=%E2%9C%93&q=cgroups&type= > > so why systemd is considered to be the only supervisor implementation > supporting cgroups? because all the rest are just libraries? > > I'm a bit confused and very curious
I have no idea. I was only aware of systemd using cgroups so far. Well except… cgmanager… which runs separately from PID 1 and supports managing processes / containers in cgroups on SysVInit (or other non cgroup based) init systems. And… well… some low latency daemon written in Lua I don´t remember… well I found it with apt-cache search: ulatencyd - scriptable latency regulator using cgroups (server) Last version packaged in Debian is from march 2014 tough. Thanks, -- Martin _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
