El sáb., 28 dic. 2019 a las 11:06, Alex Suykov escribió: > > Minor note on this. Resource limiting with cgroups does not require > any explicit support from s6, or any external tools for that matter. > Literally just `echo $$ > $cg/cgroup.procs` in the startup script > is enough, assuming the group has been created (mkdir) and the limits > have been set (bunch of echo's).
Exactly. And that's what nosh's move-to-control-group(1) and set-control-group-knob(1) do. They are convenience tools invoked by nosh scripts generated by conversion of unit files (with 'system-control convert-systemd-units'). Nosh's service manager doesn't directly deal with cgroups, and neither does its PID 1 program. > The whole thing regarding cgroups in systemd is really about a very > different problem: supervising broken services that exit early and > leave orphaned children behind. I'm not sure if it is specifically for that. AFAIK, it is an implementation detail of 'KillMode=control-group' and 'KillMode=mixed' unit file directives. Daemons that use those, like GDM, seemingly 'stay in the foreground', and can therefore be supervised, but spawn child processes (and/or threads?) that they expect someone else to kill when they exit. * https://www.freedesktop.org/software/systemd/man/systemd.kill.html#KillMode= * https://gitlab.gnome.org/GNOME/gdm/blob/3.34.1/data/gdm.service.in (A BusName directive and no Type directive means, I think, that the process can be supervised, and should be considered ready when it acquires a bus name) For those cases, I believe only the "read PIDs from cgroup.procs and kill corresponding processes until no more PIDs are read" part of the 'babysitter' functionality is needed, and IMO that fits better in the finish file, like in Oliver's example. As for the "Is there real pressure to have this?" question, I guess it depends on how many daemons that need o rely on this KillMode functionality actually exist? Do we know? G.
