Lines Matching refs:it
19 times. However, it has been updated and improved substantially, even
47 1. The **no-processes-in-inner-nodes** rule: this means that it's not permitted
50 it's an inner node it may not contain processes directly, and if it's a leaf
51 node then it may not have child cgroups. (Note that there are some minor
57 writer, i.e. a single process managing it. It's OK if different cgroups have
59 specific cgroup, and when it does that ownership is exclusive, and nothing else
60 should manipulate it at the same time. This rule ensures that various pieces of
69 soon as you add a process to a cgroup it is ensured the rule is not
71 though it's a good thing to follow it then too. Rule #2 is not enforced on
73 root can do anything, modulo SELinux and friends), but if you ignore it you'll
78 it's semantically broken in many ways, and in many cases doesn't actually do
79 what people think it does. cgroup v2 is where things are going, and most new
92 and all available controllers are exclusively exposed through it.
115 Superficially, in legacy and hybrid modes it might appear that the parallel
130 `statfs()` on `/sys/fs/cgroup/`. If it reports `CGROUP2_SUPER_MAGIC` in its
131 `.f_type` field, then you are in unified mode. If it reports `TMPFS_MAGIC` then
180 system it maps directly to the top-level directory of cgroup v2.
200 but we expose it on cgroup v1 too. Delegation means that some parts of the
201 cgroup tree may be managed by different managers than others. As long as it is
203 sub-graph of the tree whatever it wants.
208 can set for a service or scope unit. If you do, it's the cut-off point for
211 create/remove sub-cgroups inside it freely, and those then become exclusive
219 change attributes of any cgroups below it, nor will it create or remove any
221 sub-tree as it deems useful anymore.
224 will be `chown()`ed to the indicated user so that it can correctly create
225 cgroups below it. Note however that systemd will do that only in the unified
230 access to it.
236 boolean. However, since v236 it optionally takes a list of controller names
239 parameters it might happen that your service actually will get fewer
254 for your service code), and turn on delegation for it.
258 where delegation is enabled (and removes it on those cgroups where it is
268 cgroup, which means that it may not directly contain any processes. Hence, if
272 tree by the time it notifies the service manager about start-up readiness, so
282 are threaded or none –, but systemd expects it to be a regular cgroup. Thus you
283 have to nest a second cgroup beneath it which then can be threaded.)
288 cgroups for it, as you want your manager to be able to run on systemd systems.
295 directly, but then tells systemd about it. In this mode the administrator
298 or services you make it possible to run cgroup-enabled programs in your
315 pid,comm,machine`), and even gnome-system-monitor supports it.
322 you can now freely create sub-cgroups beneath it. Don't forget the
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
343 you are started in, and everything below it, whatever that might be. That said,
361 really usable, or it's very clear they have no future on cgroup v2, and we
366 code (however, systemd will still mount their hierarchies, simply because it
367 mounts all controller hierarchies it finds available in the kernel). If you
368 decide to use them, then that's fine, but systemd won't help you with it (but
369 also not interfere with it). To be nice to other tenants it might be wise to
376 up after you in the hierarchies it manages: if your daemon goes down, its
378 with a pristine cgroup sub-tree for your service or scope whenever it is
385 specific controller on cgroup v1 you can still make use of it for delegation,
389 happen through systemd itself. This means: when you update your kernel and it
390 adds a new, so far unseen controller, and you want to use it for delegation,
391 then you also need to update systemd to a version that groks it.
397 to delegate a sub-tree to it. Note that there's nothing too special you have to
399 cgroup sub-tree, and it will figure out the rest: it will determine the cgroup
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
405 of the root cgroup you pass to it *in* *full*, i.e. it will not only
406 create/remove child cgroups below it, it will also attempt to manage the
407 attributes of it. OTOH as mentioned above, when delegating a cgroup tree to
408 somebody else it only passes the rights to create/remove sub-cgroups, but will
411 *greedy* when delegating them to others: it insists on managing attributes on
419 When systemd runs as container payload it will make use of all hierarchies it
436 to a sub-cgroup of the cgroup it got delegated, too. Most likely you hence
450 is really up to you how you do it. Just do it, and be careful.
484 may change in future versions. This means: it's best to avoid implementing a
486 program, or vice versa — it's likely going to break sooner or later. Use the
495 and there it's safe to treat delegation boundaries as privilege boundaries.
497 And that's it for now. If you have further questions, refer to the systemd