Pax Controla Groupiana

aka “How to behave nicely in the cgroupfs trees”

Important Update: Please consult this document only as a historical reference. It was written under the assumption that the cgroups tree was a shared resource. However, after much discussion this concept has been deemed outdated. The cgroups tree can no longer be considered a shared resource. Instead, a management daemon of some kind needs to arbitrate access to it, and it needs to actively propagate changes between the entities it manages. More specifically, on systemd systems this management daemon is systemd itself, accessible via a number of bus APIs. This means instead of dealing directly with the low-level interfaces of the cgroup file system, please use systemd’s high-level APIs as a replacement, see the New Control Group Interfaces for details. They offer similar functionality.

Are you writing an application interfacing with the cgroups tree? The cgroups trees are a shared resource, other applications will use them too. Here are a few recommendations how to write your application in a way that minimizes conflicts with other applications. If you follow these guidelines applications should not step on any other application’s toes and users will be happy.

Before you read these recommendations please make sure you understand cgroups thoroughly, and specifically are aware what a controller is, what a named hierarchy is and so on.

Intended Audience

You should consider these recommendations if you are you working on one of the following:

General Recommendations

Cooperation with systemd

systemd adheres to the recommendations above and guarantees additional behavior which might be useful for writing applications that cooperate with systemd on cgroup management: