Lines Matching refs:of
15 what systemd has to offer there. Here's a bit of documentation about the
18 What's described here has been part of systemd and documented since v205
21 comprehensive up-to-date information about all this, particular in light of the
22 poor implementations of the components interfacing with systemd of current
43 Much of the philosophy behind these concepts is based on a couple of basic
44 design ideas of cgroup v2 (which we however try to adapt as far as we can to
49 vice versa. A cgroup is either an inner node or a leaf node of the tree, and if
60 should manipulate it at the same time. This rule ensures that various pieces of
63 These two rules have various effects. For example, one corollary of this is: if
74 be in constant pain as various pieces of software will fight over cgroup
82 support for all kinds of per-cgroup BPF magic, supports secure delegation of
96 `/sys/fs/cgroup/<controller>/`. On top of that systemd manages its own cgroup
117 systemd they are not: the hierarchies of all controllers are always kept in
122 to talk of one specific cgroup and actually mean the same cgroup in all
129 If you wonder how to detect which of these three modes is currently used, use
144 processes systemd itself starts. Units of these types have cgroups that are
145 the leaves of the cgroup tree the systemd instance manages (though possibly
146 they might contain a sub-tree of their own managed by something else, made
147 possible by the concept of delegation, see below). Service units are usually
149 invoke and other properties of the service. However, service units may also
154 difference: the processes the units of this type encapsulate are forked off
162 3. �� The `.slice` unit type. Units of this type do not directly contain any
163 processes. Units of this type are the inner nodes of part of the cgroup tree
167 Slices expose the trunk and branches of a tree, and scopes and services are
171 The naming of slice units directly maps to the cgroup tree path. This is not
179 1. `-.slice` is the root slice. i.e. the parent of everything else. On the host
180 system it maps directly to the top-level directory of cgroup v2.
185 3. `user.slice` is where user sessions are placed. Each user gets a slice of
189 placed. `systemd-nspawn` makes use of this by default, and you're very welcome
192 Users may define any amount of additional slices they like though, the four
200 but we expose it on cgroup v1 too. Delegation means that some parts of the
202 clear which manager manages which part of the tree each one can do within its
203 sub-graph of the tree whatever it wants.
212 property of your program, systemd won't touch them — all attributes of *those*
218 1. systemd won't fiddle with your sub-tree of the cgroup tree anymore. It won't
219 change attributes of any cgroups below it, nor will it create or remove any
220 cgroups thereunder, nor migrate processes across the boundaries of that
223 2. If your service makes use of the `User=` functionality, then the sub-tree
227 hierarchy (in legacy and hybrid mode). It won't pass ownership of the legacy
229 in cgroup v1 (as a limitation of the kernel), hence systemd won't facilitate
236 boolean. However, since v236 it optionally takes a list of controller names
247 our *inner* nodes of the cgroup trees and we freely attach services and scopes
265 set, then these commands will be executed within the `.control/` sub-cgroup of
269 your service has any of these four settings set, you must be prepared that a
281 this is a requirement of threaded cgroups: either a cgroup and all its siblings
308 operations as in a. The main benefit of this: this way you let the system
319 interest in integration with the rest of the system, then this is a valid
324 daemon process out of that cgroup (and into a sub-cgroup) before you can
325 start further processes in any of your sub-cgroups.
331 `Delegate=` turned on, and it would contain the PID of this process; all
349 systemd supports a number of controllers (but not all). Specifically, supported
370 replicate the cgroup hierarchies of the other controllers in them too however,
371 but of course that's between you and those other tenants, and systemd won't
385 specific controller on cgroup v1 you can still make use of it for delegation,
398 do beyond that: just invoke systemd as PID 1 inside the root of the delegated
400 it is running in and take possession of it. It won't interfere with any cgroup
401 outside of the sub-tree it was invoked in. Use of `CLONE_NEWCGROUP` is hence
402 optional (but of course wise).
405 of the root cgroup you pass to it *in* *full*, i.e. it will not only
407 attributes of it. OTOH as mentioned above, when delegating a cgroup tree to
413 of a host systemd which wants to run a systemd as its own container payload
419 When systemd runs as container payload it will make use of all hierarchies it
423 unified you (of course, I guess) need to provide only `/sys/fs/cgroup/` itself.
428 each of your containers will have its own systemd-managed unit and hence
430 running in that unit will be some kind of executor program, which will in
431 turn fork off the payload processes of the container. In this case don't
432 forget that there are two levels of delegation involved: first, systemd
435 of the no-process-in-inner-nodes rule, your executor needs to migrate itself
436 to a sub-cgroup of the cgroup it got delegated, too. Most likely you hence
439 for each container a sibling cgroup of that maybe called `payload-xyz/`.
444 arbitrary naming, you might need to escape some of the names (for example,
465 3. �� Never *write* to any of the attributes of a cgroup systemd created for
467 attributes of cgroups you created in your own delegated sub-tree, but the
468 cgroup tree of systemd itself is out of limits for you. It's fine to *read*
473 mount only a sub-tree of the host's cgroup tree into the container. Part of
474 the cgroup API is that `/proc/$PID/cgroup` reports the cgroup path of every
476 `/proc/$PID/cgroup` of the payload processes reports. What you can do safely
477 however, is mount the upper parts of the cgroup tree read-only (or even
483 naming and their cgroup paths is not considered public API of systemd, and
485 local logic of translating cgroup paths to slice/scope/service names in your
494 system with that and worse. Delegation is a strongpoint of cgroup v2 though,