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
> 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
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.
Dng mailing list