Re: The "Unix Philosophy 2020" document

From: Guillermo <>
Date: Sat, 28 Dec 2019 15:05:59 -0300

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

> 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.


(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?

Received on Sat Dec 28 2019 - 18:05:59 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC