{"action":"created","comment":{"url":"https://api.github.com/repos/systemd/systemd/pulls/comments/183112444","pull_request_review_id":114048264,"id":183112444,"diff_hunk":"@@ -0,0 +1,420 @@\n+# Control Group APIs and Delegation\n+\n+So you are wondering about resource management with systemd, you know Linux\n+control groups (cgroups) a bit and are trying to integrate your software with\n+what systemd has to offer there. Here's a bit of documentation about the\n+concepts and interfaces involved with this.\n+\n+What's described here has been part of systemd and documented since v205\n+times. However, it has been updated and improved substantially since, even\n+though the concepts stayed mostly the same. This is an attempt to provide more\n+comprehensive up-to-date information about all this, particular in light of the\n+poor implementations of the components interfacing with systemd of current\n+container managers.\n+\n+Before you read on, please make sure you read the low-level [kernel\n+documentation about\n+cgroupsv2](https://www.kernel.org/doc/Documentation/cgroup-v2.txt). This\n+documentation then adds in the higher-level view from systemd.\n+\n+This document augments the existing documentation we already have:\n+\n+* [The New Control Group Interfaces](https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/)\n+* [Writing VM and Container Managers](https://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/)\n+\n+These wiki documents are not as up to date as they should be, currently, but\n+the basic concepts still fully apply. You should read them too, if you do something\n+with cgroups and systemd, in particular as they shine more light on the various\n+D-Bus APIs provided. (That said, sooner or later we should probably fold that\n+wiki documentation into this very document, too.)\n+\n+## Two Key Design Rules\n+\n+Much of the philosophy behind these concepts is based on a couple of basic\n+design ideas of cgroupsv2 (which we however try to adapt as far as we can to\n+cgroupsv1 too). Specifically two cgroupsv2 rules are the most relevant:\n+\n+1. The **no-processes-in-inner-nodes** rule: this means that it's not permitted\n+to have processes directly attached to a cgroup that also has child cgroups and\n+vice versa. A cgroup is either an inner node or a leaf node of the tree, and if\n+it's an inner node it may not contain processes directly, and if it's a leaf\n+node then it may not have child cgroups. (Note that there are some minor\n+exceptions to this rule, though. i.e. the root cgroup is special and allows\n+both processes and children — which is used in particular to maintain kernel\n+threads.)\n+\n+2. The **single-writer** rule: this means that each cgroup only has a single\n+writer, i.e. a single process managing it. It's OK if different cgroups have\n+different processes managing them. However, only a single process should own a\n+specific cgroup, and when it does that ownership is exclusive, and nothing else\n+should manipulate it at the same time. This rule ensures that various pieces of\n+software don't step on each other's toes constantly.\n+\n+These two rules have various effects. For example, one corollary of this is: if\n+your container manager creates and manages cgroups in the system's root cgroup\n+you violate rule #2, as the root cgroup is managed by systemd and hence off\n+limits to everybody else.\n+\n+Note that rule #1 is generally enforced by the kernel if cgroupsv2 is used: as\n+soon as you add a process to a cgroup it is ensured the rule is not\n+violated. On cgroupsv1 this rule didn't exist, and hence isn't enforced, even\n+though it's a good thing to follow it then too. Rule #2 is not enforced on\n+either cgroupsv1 nor cgroupsv2 (this is UNIX after all, root can do anything),\n+but if you ignore it you'll be in constant pain as various pieces of software\n+will fight over cgroup ownership.\n+\n+Note that cgroupsv1 is currently the most deployed implementation of all of\n+this, even though it's semantically broken in many ways, and in many cases\n+doesn't actually do what people think it does. cgroupsv2 is where things are\n+going, and most new kernel features in this area are only added to cgroupsv2,\n+and not cgroupsv1 anymore. For example cgroupsv2 provides proper cgroup-empty\n+notifications, has support for all kinds of per-cgroup BPF magic, supports\n+secure delegation of cgroup trees to less privileged processes and so on, which\n+all are not available on cgroupsv1.\n+\n+## Three Different Setups\n+\n+systemd supports three different modes how cgroups are set up. Specifically:\n+\n+1. **Unified** — this is the simplest mode, and exposes a pure cgroupsv2\n+logic. In this mode `/sys/fs/cgroup` is the only mounted cgroup API file system\n+and all available controllers are exclusively exposed through it.\n+\n+2. **Legacy** — this is the traditional cgroupsv1 mode. In this mode the\n+various controllers each get their own cgroup file system mounted to\n+`/sys/fs/cgroup/<controller>/`. On top of that systemd manages its own cgroup\n+hierarchy for managing purposes as `/sys/fs/cgroup/systemd/`.\n+\n+3. **Hybrid** — this is a hybrid between the unified and legacy mode. It's set\n+up mostly like legacy, except that there's also an additional hierarchy\n+`/sys/fs/cgroup/unified/` that contains the cgroupsv2 hierarchy. In this mode\n+compatibility with cgroupsv1 is retained while some cgroupsv2 features are\n+available too. This mode is a stopgap. Don't bother with this too much unless\n+you have too much free time.\n+\n+To say this clearly, legacy and hybrid modes have no future. If you develop\n+software today and don't focus on the unified mode, then you are writing\n+software for yesterday, not tomorrow. They are primarily supported for\n+compatibility reasons and will not receive new features. Sorry.\n+\n+Superficially, in legacy and hybrid modes it might appear that the parallel\n+cgroup hierarchies for each controller are orthogonal from each other. In\n+systemd they are not: the hierarchies of all controllers are always kept in\n+sync (at least mostly: sub-trees might be suppressed in certain hierarchies if\n+no controller usage is required for them). The fact that systemd keeps these\n+hierarchies in sync means that the legacy and hybrid hierarchies are\n+conceptually very close to the unified hierarchy. In particular this allows us\n+talk of one specific cgroup and actually mean the same cgroup in all available\n+controller hierarchies. e.g. if we talk about the cgroup `/foo/bar/` then we\n+actually mean `/sys/fs/cgroup/cpu/foo/bar/` as well as\n+`/sys/fs/cgroup/memory/foo/bar/`, `/sys/fs/cgroup/pids/foo/bar/`, and so on, in\n+one. Note that in cgroupsv2 the controller hierarchies aren't orthogonal\n+anyway, hence thinking about them as orthogonal won't help you in the long run\n+anyway.\n+\n+If you wonder how to detect which of these three modes is currently used, use\n+`statfs()` on `/sys/fs/cgroup/`. If it reports `CGROUP2_SUPER_MAGIC` in its\n+`.f_type` field, then you are in unified mode. If it reports `TMPFS_MAGIC` then\n+you are either in legacy or hybrid mode. To distuingish these two cases, run\n+`statfs()` again on `/sys/fs/cgroup/unified/`. If that succeeds and reports\n+`CGROUP2_SUPER_MAGIC` you are in hybrid mode, otherwise not.\n+\n+## systemd's Unit Types\n+\n+The low-level kernel cgroups feature is exposed in systemd in three different\n+\"unit\" types. Specifically:\n+\n+1. The `.service` unit type. This unit type is for units encapsulating\n+   processes systemd itself starts. Units of these types have cgroups that are\n+   the leaves of the cgroup tree systemd manages (though possibly they might\n+   contain a sub-tree of their own managed by something else, made possible by\n+   the concept of delegation, see below). Service units are usually\n+   instantiated based on a unit file on disk that describes the command line to\n+   invoke and other properties of the service. However, service units may also\n+   be declared and started programmatically at runtime through a D-Bus API\n+   (which is called *transient* services).\n+\n+2. The `.scope` unit type. This is very similar to `.service`. The main\n+   difference: the processes the units of this type encapsulate are forked off\n+   by some unrelated manager process, and that manager asked systemd to expose\n+   them as a unit. Unlike services, scopes can only be declared and started\n+   programmatically, i.e. are always transient. That's because they encapsulate\n+   processes forked off by something else, i.e. existing runtime objects, and\n+   hence cannot really be defined fully in 'offline' concepts such as unit\n+   files.\n+\n+3. The `.slice` unit type. Units of this type do not directly contain any\n+   processes. Units of this type are the inner nodes of the cgroup tree. Much\n+   like services, slices can be defined either on disk with unit files or\n+   programmatically as transient units.\n+\n+Slices expose the trunk and branches of a tree, and scopes and services are\n+attached to those branches as leaves. The idea is that scopes and services can\n+be moved around though, i.e. assigned a different slice if needed.\n+\n+The naming of slice units directly maps to the cgroup tree path. This is not\n+the case for service and scope units however. A slice named `foo-bar-baz.slice`\n+maps to a cgroup `/foo.slice/foo-bar.slice/foo-bar-baz.slice/`. A service\n+`quux.service` which is attached to the slice `foo-bar-baz.slice` maps to the\n+cgroup `/foo.slice/foo-bar.slice/foo-bar-baz.slice/quux.service/`.\n+\n+By default systemd sets up four slice units:\n+\n+1. `-.slice` is the root slice. i.e. the parent of everything else. On the host\n+   system it maps directly to the top-level directory of cgroupsv2.\n+\n+2. `system.slice` is where system services are by default placed, unless\n+   configured otherwise.\n+\n+3. `user.slice` is where user sessions are placed. Each user gets a slice of\n+   its own below that.\n+\n+4. `machines.slice` is where VMs and containers are supposed to be\n+   placed. `systemd-nspawn` makes use of this by default, and you're very welcome\n+   to place your containers and VMs there too if you hack on managers for those.\n+\n+Users may define any amount of additional slices they like though, the four\n+above are just the defaults.\n+\n+## Delegation\n+\n+Container managers and suchlike often want to control cgroups directly using\n+the raw kernel APIs. That's entirely fine and supported, as long as proper\n+*delegation* is followed. Delegation is a concept we inherited form cgroupsv2,\n+but we expose it on cgroupsv1 too. Delegation means that some parts of the\n+cgroup tree may be managed by different managers than others. As long as it is\n+clear which manager manages which part of the tree each one can do within its\n+sub-graph of the tree whatever it wants.\n+\n+Only sub-trees can be delegated (though whoever decides to request a sub-tree\n+can delegate sub-sub-trees further to somebody else if they like\n+it). Delegation takes place at a specific cgroup: in systemd there's a\n+`Delegate=` property you can set for a service or scope unit. If you do, it's\n+the cut-off point for systemd's cgroup management: the unit itself is managed\n+by systemd, i.e. all its attributes are managed exclusively by systemd, however\n+your program may create/remove sub-cgroups inside it freely, and those then\n+become exclusive property of your program, systemd won't touch them — all\n+attributes of *those* sub-cgroups can be manipulated freely and exclusively by\n+your program.\n+\n+By turning on the `Delegate=` property for a scope or service you get a few\n+guarantees:\n+\n+1. systemd won't fiddle with your sub-tree of the cgroup tree anymore. It won't\n+   change attributes of any cgroups below it, nor will it create or remove any\n+   cgroups thereunder, nor migrate processes across the boundaries of that\n+   sub-tree as it deems useful anymore.\n+\n+2. If your service makes use of the `User=` functionality, then the sub-tree\n+   will be `chown()`ed to the indicated user so that it can correctly create\n+   cgroups below it. Note however that systemd will do that only in the unified\n+   hierarchy (in unified and hybrid mode) as well as on systemd's own private\n+   hierarchy (in legacy and hybrid mode). It won't pass ownership of the legacy\n+   controller hierarchies. Delegation to less privileges processes is not safe\n+   in cgroupsv1 (as a limitation of the kernel), hence systemd won't facilitate\n+   access to it.\n+\n+3. Any BPF IP filter programs systemd installs will be installed with\n+   `BPF_F_ALLOW_MULTI` so that your program can install additional ones.\n+\n+In unit files the `Delegate=` is superficially exposed as boolean. However,\n+since v236 it optionally takes a list of controller names instead. If so,\n+delegation is requested for listed controllers specifically. Note hat this only\n+encodes a request. Depending on various parameters it might happen that your\n+service actually will get fewer controllers delegated (for example, because the\n+controller is not available on the current kernel or was turned off) or more.\n+If no list is specified (i.e. the property simply set to `yes`) then all\n+available controllers are delegated.\n+\n+Let's stress one thing: delegation is available on scope and service units\n+only. It's expressly not available on slice units. Why that? Because slice\n+units are our *inner* nodes of the cgroup trees and we freely attach service\n+and scopes to them. If we'd allow delegation on slice units then this would\n+mean that that both systemd and your own manager would create/delete cgroups\n+below the slice unit and that conflicts with the single-writer rule.\n+\n+So, if you want to do your own raw cgroups kernel level access, then allocate a\n+scope unit, or a service unit (or just use the service unit you already have\n+for your service code), and turn on delegation for it.\n+\n+## Three Scenarios\n+\n+Let's say you write a container manager, and you wonder what to do regarding\n+cgroups for it, as you want your manager to be able to run on systemd systems.\n+\n+You basically have three options:\n+\n+1. The *integration-is-good* option. For this, you register each container you\n+   have either as systemd service (i.e. let systemd invoke the executor binary\n+   for you) or systemd scope (i.e. your manager executes the binary directly,\n+   but then tells systemd about it. In this mode the administrator can use the\n+   usual systemd resource management commands individually on containers. By\n+   turning on `Delegate=` for these scopes or services you make it possible to\n+   run cgroup-enabled programs in your containers, for example a systemd\n+   instance running inside it. This option has two sub-options:\n+\n+   a. You register the service or scope transiently directly by contacting\n+      systemd. In this case systemd will just manage the unit for you and nothing else.\n+\n+   b. Instead you register the service or scope through\n+      `systemd-machined`. This mini-daemon is basically just a proxy for the\n+      same operations as in a. The main benefit of this: this way you let the\n+      system know that what you are registering is a container, and this opens\n+      up certain additional integration points. For example, `journalctl -M`\n+      can then be used to directly look into any container's journal logs\n+      (should the container run systemd inside), or `systemctl -M` can be used\n+      to directly invoke systemd operations inside the containers. Moreover\n+      tools like \"ps\" can then show you to which container a process belongs\n+      (`ps -eo pid,comm,machine`), and even gnome-system-monitor supports it.\n+\n+2. The *i-like-islands* option. If all you care about is your own cgroup tree,\n+   and you want to have to do as little as possible with systemd and no\n+   interest in integration with the rest of the system, then this is a valid\n+   option. For this all you have to do is turn on `Delegate=` for your main\n+   manager daemon. Then figure out the cgroup systemd placed your daemon in:\n+   you can now freely create sub-cgroups beneath it. Don't forget the\n+   *no-processes-in-inner-nodes* rule however: you have to move your main\n+   daemon process out of that cgroup (and into a sub-cgroup) before you can\n+   start further processes in any of your sub-cgroups.\n+\n+3. The *i-like-continents* option. In this option you'd leave your manager\n+   daemon where it is, and would not turn on delegation on its unit. However,\n+   as first thing you register a new scope unit with systemd, and that scope\n+   unit would have `Delegate=` turned on, and then you place all your\n+   containers underneath it. From systemd's PoV there'd be two units: your\n+   manager service and the big scope that contains all your containers in one.\n+\n+BTW: if for whatever reason you say \"I hate D-Bus, I'll never call any D-Bus\n+API, kthxbye\", then options #1 and #3 are not available, as they generally\n+involve talking to systemd from your program code, via D-Bus. You still have\n+option #2 in that case however, as you can simply set `Delegate=` in your\n+service's unit file and you are done and have your own sub-tree. In fact, #2 is\n+the one option that allows you to completely ignore systemd's existence: you\n+can entirely generically follow the single rule that you just use the cgroup\n+you are started in, and everything below it, whatever that might be. That said,\n+maybe if you dislike D-Bus and systemd that much, the better approach might be\n+to work on that, and widen your horizon a bit. You are welcome.\n+\n+## Controller Support\n+\n+systemd supports a number of controllers, but not all. Specifically:\n+\n+* on cgroupsv1: `cpu`, `cpuacct`, `blkio`, `memory`, `devices`, `pids`\n+* on cgroupsv2: `cpu`, `io`, `memory`, `pids`\n+\n+It is our intention to natively support all cgroupsv2 controllers that might\n+come up sooner or later. However, regarding cgroupsv1: at this point we will\n+not add support for any other controllers anymore. This means systemd currently\n+does not and will never manage the following controllers on cgroupsv1:\n+`freezer`, `cpuset`, `net_cls`, `perf_event`, `net_prio`, `hugetlb`. Why not?\n+Depending on the case, either their API semantics or implementations aren't\n+really usable, or it's very clear they have no future on cgroupsv2, and we\n+won't add new code for stuff that clearly has no future.\n+\n+Effectively this means that all those mentioned cgroupsv1 controllers are up\n+for grabs: systemd won't manage them, and hence won't delegate them to your\n+code (however, systemd will still mount their hierarchies, simply because it\n+mounts all controller hierarchies it finds available in the kernel). If you\n+decide to use them, then that's fine, but systemd won't help you with it (but\n+also not interfere with it). To be nice to other tenants it might be wise to\n+replicate the cgroup hierarchies of the other controllers in them too however,\n+but of course that's between you and those other tenants, and systemd won't\n+care.\n+\n+## systemd as Container Payload\n+\n+systemd can happily run as a container payload's PID 1. Note that systemd\n+unconditionally needs write access to the cgroup tree however, hence you need\n+to delegate a sub-tree to it. Note that there's nothing too special you have to\n+do beyond that: just invoke systemd as PID 1 inside the root of the delegated\n+cgroup sub-tree, and it will figure out the rest: it will determine the cgroup\n+it is running in and take possession of it. It won't interfere with any cgroup\n+outside of the sub-tree it was invoked in. Use of `CLONE_NEWCGROUP` is hence\n+optional (but of course wise).\n+\n+Note one particular asymmetry here though: systemd will try to take possession\n+of the root cgroup you pass to it *in* *full*, i.e. it will not only\n+create/remove child cgroups below it it will also attempt to manage the\n+attributes of it. OTOH as mentioned above, when delegating a cgroup tree to\n+somebody else it only passes the rights to create/remove sub-cgroups, but will\n+insist on managing the delegated cgroup tree's top-level attributes. Or in\n+other words: systemd is *greedy* when accepting delegated cgroup trees and also\n+*greedy* when delegating them to others: it insists on managing attributes on\n+the specific cgroup in both cases. A container manager that is itself a payload\n+of a host systemd which wants to run a systemd as its own container payload\n+instead hence needs to insert an extra level in the hierarchy in between, so\n+that the systemd on the host and the container won't fight for the\n+attributes. That said, you likely should do that anyway, due to the\n+no-processes-in-inner-cgroups rule, see below.\n+\n+When systemd runs as container payload it will make use of all hierarchies it\n+has write access to. For legacy mode you need to make at least\n+`/sys/fs/cgroup/systemd/` available, all other hierarchies are optional. For\n+hybrid mode you need to add `/sys/fs/cgroup/unified/`. Finally, for fully\n+unified you (of course, I guess) need to provide only `/sys/fs/cgroup/` itself.\n+\n+## Some Dos\n+\n+1. If you go for implementation option 1a or 1b (as in the list above), then\n+   each of your containers will have its own systemd-managed unit and hence\n+   cgroup with possibly further sub-cgroups below. Typically the first process\n+   running in that unit will be some kind of executor program, which will in\n+   turn fork off the payload processes of the container. In this case don't\n+   forget that there are two levels of delegation involved: first, systemd\n+   delegates a group sub-tree to your executor. And then your executor should\n+   delegate a sub-tree further down to the container payload. Oh, and because\n+   of the no-process-in-inner-nodes rule, your executor needs to migrate itself\n+   to a sub-cgroup of the cgroup it got delegated, too. Most likely you hence\n+   want a two-pronged approach: below the cgroup you got started in, you want\n+   one cgroup maybe called `supervisor/` where your manager runs in and then\n+   for each container a sibling cgroup of that maybe called `payload-xyz/`.\n+\n+2. Don't forget that the cgroups you create have to have names that are\n+   suitable as UNIX file names, and that they live in the same namespace as the\n+   various kernel attribute files. Hence, when you want to allow the user\n+   arbitrary naming, you might need to escape some of the names (for example,\n+   you really don't want to create a cgroup named `tasks`, just because the\n+   user created a container by that name, because `tasks` after all is a magic\n+   attribute in cgroupsv1, and you `mkdir()` will hence fail with `EEXIST`. In\n+   systemd we do escaping by prefixing names that might collide with a kernel\n+   attribute name with an underscore. You might want to do the same, but this\n+   is really up to you how you do it. Just do it, and be careful.\n+\n+## Some Don'ts\n+\n+1. Never create your own cgroups below arbitrary cgroups systemd manages, i.e\n+   cgroups you haven't set `Delegate=` in. Specifically: don't create your own\n+   cgroups below the root cgroup. That's owned by systemd, and you will step on\n+   systemd's toes if you ignore that, and systemd will step on yours. Get your\n+   own delegated sub-tree, you may create as many cgroups there as you\n+   like. Seriously, if you create cgroups directly in the cgroup root, then all\n+   you do is ask for trouble.\n+\n+2. Don't attempt to set `Delegate=` in slice units, and in particular not in\n+   `-.slice`. It's not supported, and will generate an error.\n+\n+2. Never *write* to any of the attributes of a cgroup systemd created for\n+   you. It's systemd's private property. You are welcome to manipulate the\n+   attributes of cgroups you created in your own delegated sub-tree, but the\n+   cgroup tree of systemd itself is out of limits for you. It's fine to *read*\n+   from any attribute you like however. That's totally OK and welcome.\n+\n+3. When not using `CLONE_NEWCGROUP` when delegating a sub-tree to a container\n+   payload running systemd, then don't get the idea that you can bind mount\n+   only a sub-tree of the host's cgroup tree into the container. Part of the\n+   cgroup API is that `/proc/$PID/cgroup` reports the cgroup path of every\n+   process, and hence any path below `/sys/fs/cgroup/` needs to match what\n+   `/proc/$PID/group` of the payload processes reports. What you can do safely","path":"doc/CGROUP_DELEGATION.md","position":407,"original_position":407,"commit_id":"503ef1148317108453dbe33f7ad71472a0974979","original_commit_id":"503ef1148317108453dbe33f7ad71472a0974979","user":{"login":"filbranden","id":106037,"avatar_url":"https://avatars0.githubusercontent.com/u/106037?v=4","gravatar_id":"","url":"https://api.github.com/users/filbranden","html_url":"https://github.com/filbranden","followers_url":"https://api.github.com/users/filbranden/followers","following_url":"https://api.github.com/users/filbranden/following{/other_user}","gists_url":"https://api.github.com/users/filbranden/gists{/gist_id}","starred_url":"https://api.github.com/users/filbranden/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/filbranden/subscriptions","organizations_url":"https://api.github.com/users/filbranden/orgs","repos_url":"https://api.github.com/users/filbranden/repos","events_url":"https://api.github.com/users/filbranden/events{/privacy}","received_events_url":"https://api.github.com/users/filbranden/received_events","type":"User","site_admin":false},"body":"typo: `/proc/$PID/group` -> `/proc/$PID/cgroup`","created_at":"2018-04-20T17:02:17Z","updated_at":"2018-04-20T17:04:54Z","html_url":"https://github.com/systemd/systemd/pull/8778#discussion_r183112444","pull_request_url":"https://api.github.com/repos/systemd/systemd/pulls/8778","author_association":"MEMBER","_links":{"self":{"href":"https://api.github.com/repos/systemd/systemd/pulls/comments/183112444"},"html":{"href":"https://github.com/systemd/systemd/pull/8778#discussion_r183112444"},"pull_request":{"href":"https://api.github.com/repos/systemd/systemd/pulls/8778"}}},"pull_request":{"url":"https://api.github.com/repos/systemd/systemd/pulls/8778","id":183108145,"html_url":"https://github.com/systemd/systemd/pull/8778","diff_url":"https://github.com/systemd/systemd/pull/8778.diff","patch_url":"https://github.com/systemd/systemd/pull/8778.patch","issue_url":"https://api.github.com/repos/systemd/systemd/issues/8778","number":8778,"state":"open","locked":false,"title":"some docs regarding cgroup delegation and systemd","user":{"login":"poettering","id":2130732,"avatar_url":"https://avatars1.githubusercontent.com/u/2130732?v=4","gravatar_id":"","url":"https://api.github.com/users/poettering","html_url":"https://github.com/poettering","followers_url":"https://api.github.com/users/poettering/followers","following_url":"https://api.github.com/users/poettering/following{/other_user}","gists_url":"https://api.github.com/users/poettering/gists{/gist_id}","starred_url":"https://api.github.com/users/poettering/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/poettering/subscriptions","organizations_url":"https://api.github.com/users/poettering/orgs","repos_url":"https://api.github.com/users/poettering/repos","events_url":"https://api.github.com/users/poettering/events{/privacy}","received_events_url":"https://api.github.com/users/poettering/received_events","type":"User","site_admin":false},"body":"Hmm, maybe let's merge this quickly unless there's something really major broken. if you have additions or so, please post a follow-up PR or so instead. This is docs after all, and won't break stuff.","created_at":"2018-04-20T16:12:56Z","updated_at":"2018-04-20T17:04:54Z","closed_at":null,"merged_at":null,"merge_commit_sha":"fba018e4f80c24661411963702449bd524e6f107","assignee":null,"assignees":[],"requested_reviewers":[],"requested_teams":[],"labels":[{"id":219550649,"url":"https://api.github.com/repos/systemd/systemd/labels/documentation","name":"documentation","color":"bfe5bf","default":false}],"milestone":null,"commits_url":"https://api.github.com/repos/systemd/systemd/pulls/8778/commits","review_comments_url":"https://api.github.com/repos/systemd/systemd/pulls/8778/comments","review_comment_url":"https://api.github.com/repos/systemd/systemd/pulls/comments{/number}","comments_url":"https://api.github.com/repos/systemd/systemd/issues/8778/comments","statuses_url":"https://api.github.com/repos/systemd/systemd/statuses/503ef1148317108453dbe33f7ad71472a0974979","head":{"label":"poettering:cgroup-delegation-doc","ref":"cgroup-delegation-doc","sha":"503ef1148317108453dbe33f7ad71472a0974979","user":{"login":"poettering","id":2130732,"avatar_url":"https://avatars1.githubusercontent.com/u/2130732?v=4","gravatar_id":"","url":"https://api.github.com/users/poettering","html_url":"https://github.com/poettering","followers_url":"https://api.github.com/users/poettering/followers","following_url":"https://api.github.com/users/poettering/following{/other_user}","gists_url":"https://api.github.com/users/poettering/gists{/gist_id}","starred_url":"https://api.github.com/users/poettering/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/poettering/subscriptions","organizations_url":"https://api.github.com/users/poettering/orgs","repos_url":"https://api.github.com/users/poettering/repos","events_url":"https://api.github.com/users/poettering/events{/privacy}","received_events_url":"https://api.github.com/users/poettering/received_events","type":"User","site_admin":false},"repo":{"id":37097921,"name":"systemd","full_name":"poettering/systemd","owner":{"login":"poettering","id":2130732,"avatar_url":"https://avatars1.githubusercontent.com/u/2130732?v=4","gravatar_id":"","url":"https://api.github.com/users/poettering","html_url":"https://github.com/poettering","followers_url":"https://api.github.com/users/poettering/followers","following_url":"https://api.github.com/users/poettering/following{/other_user}","gists_url":"https://api.github.com/users/poettering/gists{/gist_id}","starred_url":"https://api.github.com/users/poettering/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/poettering/subscriptions","organizations_url":"https://api.github.com/users/poettering/orgs","repos_url":"https://api.github.com/users/poettering/repos","events_url":"https://api.github.com/users/poettering/events{/privacy}","received_events_url":"https://api.github.com/users/poettering/received_events","type":"User","site_admin":false},"private":false,"html_url":"https://github.com/poettering/systemd","description":"systemd upstream","fork":true,"url":"https://api.github.com/repos/poettering/systemd","forks_url":"https://api.github.com/repos/poettering/systemd/forks","keys_url":"https://api.github.com/repos/poettering/systemd/keys{/key_id}","collaborators_url":"https://api.github.com/repos/poettering/systemd/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/poettering/systemd/teams","hooks_url":"https://api.github.com/repos/poettering/systemd/hooks","issue_events_url":"https://api.github.com/repos/poettering/systemd/issues/events{/number}","events_url":"https://api.github.com/repos/poettering/systemd/events","assignees_url":"https://api.github.com/repos/poettering/systemd/assignees{/user}","branches_url":"https://api.github.com/repos/poettering/systemd/branches{/branch}","tags_url":"https://api.github.com/repos/poettering/systemd/tags","blobs_url":"https://api.github.com/repos/poettering/systemd/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/poettering/systemd/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/poettering/systemd/git/refs{/sha}","trees_url":"https://api.github.com/repos/poettering/systemd/git/trees{/sha}","statuses_url":"https://api.github.com/repos/poettering/systemd/statuses/{sha}","languages_url":"https://api.github.com/repos/poettering/systemd/languages","stargazers_url":"https://api.github.com/repos/poettering/systemd/stargazers","contributors_url":"https://api.github.com/repos/poettering/systemd/contributors","subscribers_url":"https://api.github.com/repos/poettering/systemd/subscribers","subscription_url":"https://api.github.com/repos/poettering/systemd/subscription","commits_url":"https://api.github.com/repos/poettering/systemd/commits{/sha}","git_commits_url":"https://api.github.com/repos/poettering/systemd/git/commits{/sha}","comments_url":"https://api.github.com/repos/poettering/systemd/comments{/number}","issue_comment_url":"https://api.github.com/repos/poettering/systemd/issues/comments{/number}","contents_url":"https://api.github.com/repos/poettering/systemd/contents/{+path}","compare_url":"https://api.github.com/repos/poettering/systemd/compare/{base}...{head}","merges_url":"https://api.github.com/repos/poettering/systemd/merges","archive_url":"https://api.github.com/repos/poettering/systemd/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/poettering/systemd/downloads","issues_url":"https://api.github.com/repos/poettering/systemd/issues{/number}","pulls_url":"https://api.github.com/repos/poettering/systemd/pulls{/number}","milestones_url":"https://api.github.com/repos/poettering/systemd/milestones{/number}","notifications_url":"https://api.github.com/repos/poettering/systemd/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/poettering/systemd/labels{/name}","releases_url":"https://api.github.com/repos/poettering/systemd/releases{/id}","deployments_url":"https://api.github.com/repos/poettering/systemd/deployments","created_at":"2015-06-08T23:07:59Z","updated_at":"2018-03-24T12:53:40Z","pushed_at":"2018-04-20T16:36:44Z","git_url":"git://github.com/poettering/systemd.git","ssh_url":"git@github.com:poettering/systemd.git","clone_url":"https://github.com/poettering/systemd.git","svn_url":"https://github.com/poettering/systemd","homepage":"http://www.freedesktop.org/wiki/Software/systemd/","size":88822,"stargazers_count":11,"watchers_count":11,"language":"C","has_issues":false,"has_projects":true,"has_downloads":true,"has_wiki":false,"has_pages":false,"forks_count":2,"mirror_url":null,"archived":false,"open_issues_count":0,"license":{"key":"gpl-2.0","name":"GNU General Public License v2.0","spdx_id":"GPL-2.0","url":"https://api.github.com/licenses/gpl-2.0"},"forks":2,"open_issues":0,"watchers":11,"default_branch":"master"}},"base":{"label":"systemd:master","ref":"master","sha":"4c3879863a5b35f3ccc3fe9bba2b629702a7469d","user":{"login":"systemd","id":1918868,"avatar_url":"https://avatars0.githubusercontent.com/u/1918868?v=4","gravatar_id":"","url":"https://api.github.com/users/systemd","html_url":"https://github.com/systemd","followers_url":"https://api.github.com/users/systemd/followers","following_url":"https://api.github.com/users/systemd/following{/other_user}","gists_url":"https://api.github.com/users/systemd/gists{/gist_id}","starred_url":"https://api.github.com/users/systemd/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/systemd/subscriptions","organizations_url":"https://api.github.com/users/systemd/orgs","repos_url":"https://api.github.com/users/systemd/repos","events_url":"https://api.github.com/users/systemd/events{/privacy}","received_events_url":"https://api.github.com/users/systemd/received_events","type":"Organization","site_admin":false},"repo":{"id":32873313,"name":"systemd","full_name":"systemd/systemd","owner":{"login":"systemd","id":1918868,"avatar_url":"https://avatars0.githubusercontent.com/u/1918868?v=4","gravatar_id":"","url":"https://api.github.com/users/systemd","html_url":"https://github.com/systemd","followers_url":"https://api.github.com/users/systemd/followers","following_url":"https://api.github.com/users/systemd/following{/other_user}","gists_url":"https://api.github.com/users/systemd/gists{/gist_id}","starred_url":"https://api.github.com/users/systemd/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/systemd/subscriptions","organizations_url":"https://api.github.com/users/systemd/orgs","repos_url":"https://api.github.com/users/systemd/repos","events_url":"https://api.github.com/users/systemd/events{/privacy}","received_events_url":"https://api.github.com/users/systemd/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/systemd/systemd","description":"⚙️ 🐧 systemd System and Service Manager ","fork":false,"url":"https://api.github.com/repos/systemd/systemd","forks_url":"https://api.github.com/repos/systemd/systemd/forks","keys_url":"https://api.github.com/repos/systemd/systemd/keys{/key_id}","collaborators_url":"https://api.github.com/repos/systemd/systemd/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/systemd/systemd/teams","hooks_url":"https://api.github.com/repos/systemd/systemd/hooks","issue_events_url":"https://api.github.com/repos/systemd/systemd/issues/events{/number}","events_url":"https://api.github.com/repos/systemd/systemd/events","assignees_url":"https://api.github.com/repos/systemd/systemd/assignees{/user}","branches_url":"https://api.github.com/repos/systemd/systemd/branches{/branch}","tags_url":"https://api.github.com/repos/systemd/systemd/tags","blobs_url":"https://api.github.com/repos/systemd/systemd/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/systemd/systemd/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/systemd/systemd/git/refs{/sha}","trees_url":"https://api.github.com/repos/systemd/systemd/git/trees{/sha}","statuses_url":"https://api.github.com/repos/systemd/systemd/statuses/{sha}","languages_url":"https://api.github.com/repos/systemd/systemd/languages","stargazers_url":"https://api.github.com/repos/systemd/systemd/stargazers","contributors_url":"https://api.github.com/repos/systemd/systemd/contributors","subscribers_url":"https://api.github.com/repos/systemd/systemd/subscribers","subscription_url":"https://api.github.com/repos/systemd/systemd/subscription","commits_url":"https://api.github.com/repos/systemd/systemd/commits{/sha}","git_commits_url":"https://api.github.com/repos/systemd/systemd/git/commits{/sha}","comments_url":"https://api.github.com/repos/systemd/systemd/comments{/number}","issue_comment_url":"https://api.github.com/repos/systemd/systemd/issues/comments{/number}","contents_url":"https://api.github.com/repos/systemd/systemd/contents/{+path}","compare_url":"https://api.github.com/repos/systemd/systemd/compare/{base}...{head}","merges_url":"https://api.github.com/repos/systemd/systemd/merges","archive_url":"https://api.github.com/repos/systemd/systemd/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/systemd/systemd/downloads","issues_url":"https://api.github.com/repos/systemd/systemd/issues{/number}","pulls_url":"https://api.github.com/repos/systemd/systemd/pulls{/number}","milestones_url":"https://api.github.com/repos/systemd/systemd/milestones{/number}","notifications_url":"https://api.github.com/repos/systemd/systemd/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/systemd/systemd/labels{/name}","releases_url":"https://api.github.com/repos/systemd/systemd/releases{/id}","deployments_url":"https://api.github.com/repos/systemd/systemd/deployments","created_at":"2015-03-25T15:27:27Z","updated_at":"2018-04-20T15:19:17Z","pushed_at":"2018-04-20T16:36:46Z","git_url":"git://github.com/systemd/systemd.git","ssh_url":"git@github.com:systemd/systemd.git","clone_url":"https://github.com/systemd/systemd.git","svn_url":"https://github.com/systemd/systemd","homepage":"https://www.freedesktop.org/wiki/Software/systemd/","size":88722,"stargazers_count":3056,"watchers_count":3056,"language":"C","has_issues":true,"has_projects":false,"has_downloads":true,"has_wiki":false,"has_pages":false,"forks_count":1216,"mirror_url":null,"archived":false,"open_issues_count":904,"license":{"key":"gpl-2.0","name":"GNU General Public License v2.0","spdx_id":"GPL-2.0","url":"https://api.github.com/licenses/gpl-2.0"},"forks":1216,"open_issues":904,"watchers":3056,"default_branch":"master"}},"_links":{"self":{"href":"https://api.github.com/repos/systemd/systemd/pulls/8778"},"html":{"href":"https://github.com/systemd/systemd/pull/8778"},"issue":{"href":"https://api.github.com/repos/systemd/systemd/issues/8778"},"comments":{"href":"https://api.github.com/repos/systemd/systemd/issues/8778/comments"},"review_comments":{"href":"https://api.github.com/repos/systemd/systemd/pulls/8778/comments"},"review_comment":{"href":"https://api.github.com/repos/systemd/systemd/pulls/comments{/number}"},"commits":{"href":"https://api.github.com/repos/systemd/systemd/pulls/8778/commits"},"statuses":{"href":"https://api.github.com/repos/systemd/systemd/statuses/503ef1148317108453dbe33f7ad71472a0974979"}},"author_association":"OWNER"}}
{"actor":{"display_login":"filbranden"}}