Lines Matching refs:on

10 *Intended audience: hackers working on userspace subsystems that require direct
25 Before you read on, please make sure you read the low-level kernel
37 with cgroups and systemd, in particular as they shine more light on the various
43 Much of the philosophy behind these concepts is based on a couple of basic
61 software don't step on each other's toes constantly.
71 though it's a good thing to follow it then too. Rule #2 is not enforced on
83 cgroup trees to less privileged processes and so on, which all are not
84 available on cgroup v1.
111 software today and don't focus on the unified mode, then you are writing
125 `/sys/fs/cgroup/memory/foo/bar/`, `/sys/fs/cgroup/pids/foo/bar/`, and so on.
130 `statfs()` on `/sys/fs/cgroup/`. If it reports `CGROUP2_SUPER_MAGIC` in its
133 `statfs()` again on `/sys/fs/cgroup/unified/`. If that succeeds and reports
148 instantiated based on a unit file on disk that describes the command line to
165 either on disk with unit files or programmatically as transient units.
190 to place your containers and VMs there too if you hack on managers for those.
200 but we expose it on cgroup v1 too. Delegation means that some parts of the
215 By turning on the `Delegate=` property for a scope or service you get a few
226 hierarchy (in unified and hybrid mode) as well as on systemd's own private
238 specifically. Note that this only encodes a request. Depending on various
240 controllers delegated (for example, because the controller is not available on
245 Let's stress one thing: delegation is available on scope and service units
246 only. It's expressly not available on slice units. Why? Because slice units are
248 to them. If we'd allow delegation on slice units then this would mean that
254 for your service code), and turn on delegation for it.
257 `getxattr(2)` and related calls) to the character `1` on cgroup directories
258 where delegation is enabled (and removes it on those cgroups where it is
260 was delegated to them. Note that this is only supported on kernels 5.6 and
263 (OK, here's one caveat: if you turn on delegation for a service, and that
266 your service's cgroup. This is necessary because by turning on delegation we
278 turned delegation on for. Why that? You need one level so that systemd can
288 cgroups for it, as you want your manager to be able to run on systemd systems.
297 individually on those containers. By turning on `Delegate=` for these scopes
320 option. For this all you have to do is turn on `Delegate=` for your main
328 daemon where it is, and would not turn on delegation on its unit. However,
331 `Delegate=` turned on, and it would contain the PID of this process; all
345 to work on that, and widen your horizon a bit. You are welcome.
352 * on cgroup v1: `cpu`, `cpuacct`, `blkio`, `memory`, `devices`, `pids`
353 * on cgroup v2: `cpu`, `io`, `memory`, `pids`
358 does not and will never manage the following controllers on cgroup v1:
360 Depending on the case, either their API semantics or implementations aren't
361 really usable, or it's very clear they have no future on cgroup v2, and we
385 specific controller on cgroup v1 you can still make use of it for delegation,
387 as necessary (as suggested above). However, on cgroup v2 this is different:
409 insist on managing the delegated cgroup tree's top-level attributes. Or in
411 *greedy* when delegating them to others: it insists on managing attributes on
415 that the systemd on the host and the one in the container won't fight for the
457 step on systemd's toes if you ignore that, and systemd will step on