Add a portal to manage cgroups

[nishalkulkarni]

Implementing a way for large applications to manage multiple worker processes will be beneficial in providing better resource distribution and isolating bad actors.

A portal where one can manage worker processes independently of systemd is one solution to this. It will allow applications to further divide their processes into separate scopes(cgroups) and provide more information about them. The desktop environment (resource control daemons) can then act on this information if desired.

The portal would provide the following features:

• Spawn/Move processes into a new/existing cgroup - Spawning a new process in the same namespace as the calling process. This enables terminating individual bad actors instead of terminating the entire application. Moving allows for the grouping of similar helper processes and enables resources control daemons to work effectively using the metadata provided. The end result for both cases is that the process ends up in a separate cgroup.

• Permit setting "properties" on each cgroup - the portal can provide a fixed set of properties associated with a cgroup, this can be achieved by setting extended attribute user.xdg.

Building upon these features we can then allow an application to set an active or inactive scope, allowing external daemons to preferentially allocate resources.

The ideas mentioned above are from Benjamin Berg's original proposal, we are currently seeking wider feedback before proceeding to implement it. I will be working on this as a part of my GSoC 2021 project.

Edit 1: To add to "why we want this" there are a lot of advantages of not considering large applications as a single entity.

systemd-oomd for example always kills a whole cgroup. So in case of a browser it will kill the entire browser and not one of its worker processes. Implementing the above can allow us to kill a worker process of an inactive tab and have lesser impact to the experience as compared killing an entire application.

[benzea]

Proposal for a cgroup portal

Modern Linux Desktops place each application into its own cgroup using systemd. At this point, the infrastructure for this is well established and doing so has a lot of benefits. From correctly displaying resource consumptions of applications, to improving resource distribution and isolation between applications.

However, some applications, in particular browsers, tend to be large. In a lot of ways these are a single applications, but there are advantages to not always consider them as a single item.

This has become very apparent with the introduction of systemd-oomd, which will always kill a whole cgroup. In the case of browsers, this currently means that the whole browser will be killed, even if it would be sufficient to kill one of its worker processes. Even better, if we can prefer killing a worker process that corresponds to an inactive tab.

Requirements

As per the above introduction, the following considerations are relevant:

• Splitting workers into a different systemd unit would make it harder to group them in case an application has multiple truely separate instances.
• An application should be capable of conveying some metadata about workers. In the case of a browser, that means conveying whether killing a worker would impact the user experience or not (e.g. visible or playing audio).
• Applications should be able to do this without access to systemd.

Having a hierarchical layout, where the workers and main application are part of the same cgroup and all workers are sibblings lends itself to this.

It does however imply that Delegate=yes is set for the systemd unit. A hierarchical layout also implies that applications compete against each other rather than all their corresponding workers. This could for example result in a higher than expected priority for an inactive tab due to the browser being active.

Proposal

The proposed solution is to manage worker cgroups independently of systemd using an XDG portal. The portal would:

• Move or spawn processes into new or existing cgroup
• Permit setting "properties" on each cgroup

The XDG portal would provide a fixed set of properties, that are attached to the cgroup by setting the xattr user.xdg.. Currently defined is:

• inactive-since: Timestamp (or -1 for currently active)

See below for a possible API, the proposal has the following known caveats:

• Properties cannot be set before a cgroup has been created.
  However, this is not a big deal, as short delays must be expected when properties are updated.
• Initially all PIDs need to be in a "root" cgroup or moved there.
  If the application only starts using the API late, then resources may not be properly accounted to the main "root" cgroup.
  Probably not a big deal, as we want to prefer it anyway, but not optimal.
• Adding properties requires adding new API.

Alternatives

The main alternative would be for applications to launch separate systemd units themselves. This method is preferential for e.g. launching long running background tasks into background.slice (e.g. for backup solutions). Ideally applications will create separate DBus services in order to do so. However, this approach will invariable split applications across multiple systemd units and does not allow dynamic resource allocation changes on its own.

Another alternative is for applications to manage the cgroup hierarchy themselves. This method is feasible, in particular if sandboxed applications could be permitted direct access to their cgroup hierarchy. This puts the burden on application developers to detect various setups though and providing an XDG portal API might be simpler in the long run.

<?xml version="1.0"?>
<!--
 Copyright (C) 2021 Red Hat, Inc.

 This library is free software; you can redistribute it and/or
 modify it under the terms of the GNU Lesser General Public
 License as published by the Free Software Foundation; either
 version 2 of the License, or (at your option) any later version.

 This library is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 Lesser General Public License for more details.

 You should have received a copy of the GNU Lesser General Public
 License along with this library. If not, see <http://www.gnu.org/licenses/>.

 Author: Benjamin Berg <[email protected]>
-->

<node name="/" xmlns:doc="http://www.freedesktop.org/dbus/1.0/doc.dtd">
  <!--
    org.freedesktop.portal.ResourceControl:
    @short_description: Portal for desktop resource controll integration

    Modern Linux desktops use systemd and cgroups to manage applications.
    Using this portal, applications are able to further separate their
    processes into separate scopes (cgroups) and provide further information
    about them.

    Internally, this works by moving the processes into separate cgroups.
    If a process does a normal fork/exec/clone the resulting PID will belong
    to the same cgroup. Once such a scope (cgroup) is created, the API user
    can set further properties in order to provide more information.

    An example use case would be browsers. These could create a new scope
    for each worker process corresponding to a tab. Then, when the user
    switches tab the browser will call SetActive() in order to mark the
    corresponding workers as active/inactive.

    An application intending to use this API should call MovePid() with
    its main process early on, in order to ensure that resource accounting
    works well.

    There is no guarantee that the desktop environment will make use of the
    provided information.
  -->
  <interface name="org.freedesktop.portal.ResourceControl">
    <!--
      Spawn:
      @target: Label refering to the target resource control scope
      @exec: Full path of the executable to launch
      @argv: Process arguments, including argv[0]
      @env: Full environment to set
      @fds: List of FDs to pass to executable
      @extra: Dictionary for extensibility, currently unused
      @result: pidfd for the process

      Spawns a new process in the same namespace as the calling process. Using
      this call allows placing a process into a separate scope (cgroup) which
      has a number of advantages. For example, should the helper process need
      too many resouces, then only the helper will be killed rather than all
      application process.

      Using @target, it is possible to group multiple process and provide
      metadata so that resource control daemons can work effectively.

      On success, a pidfd for the new process is returned in @result. This
      permits watching for process termination.
    -->
    <method name='Spawn'>
      <arg type="s" name="target" direction="in"/>
      <arg type="s" name="exec" direction="in"/>
      <arg type="as" name="argv" direction="in"/>
      <arg type="a{ss}" name="env" direction="in"/>
      <arg type="a(uh)" name="fds" direction="in"/>
      <!-- XXX: Add a "flags" parameter? -->
      <arg type="a{sv}" name="extra" direction="in"/>

      <arg type="h" name="result" direction="out"/>
    </method>

    <!--
      MovePid:
      @target: Label refering to the target resource control scope
      @process: pidfd referring to the process that should be moved

      Moves an already spawned helper process into the separate scope (cgroup)
      that is refered to by @label.

      Using @label, it is possible to group multiple process and provide
      metadata so that resource control daemons can work effectively.

      It is better to use SpawnHelper rather than moving process later as
      resources consumed before the move may not be accounted correctly.
    -->
    <method name='MovePid'>
      <arg type="s" name="target" direction="in"/>
      <arg type="h" name="process" direction="in"/>
    </method>

    <!--
      SetActive:
      @target: Label refering to the target resource control scope
      @active: Whether @target should be considered active.

      Mark the scope with name @target as active or inactive depending on the
      value of @active.
    -->
    <method name='SetActive'>
      <arg type="s" name="target" direction="in"/>
      <arg type="b" name="active" direction="in"/>
    </method>
    </interface>
</node>

[hadess]

It might be a good idea to come up with an easy-to-use non-sandboxed API, and have some users (even with WIP patches) before writing a portal. If there is an existing API, could you please link to it? If there's already an API, is this portal API the minimum API required to implement the higher-level API?

Having API users would help with figuring out whether the API is acceptable and usable. Would also be nice to have references to what other OSes use in similar circumstances.

[davidedmundson]

@hadess we somewhat have an existing non-sandboxed API for MovePID and Spawn at a session level for whole applications.
Both are org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartTransientUnit and then requires populating some complicated struts.

https://invent.kde.org/-/snippets/1111 has easier to read code examples of that.
This API is currently in use by both gnome and KDE library code when spawning new apps.

In terms of examples /within/ applications gnome's VTE is the only example I can think of. Currently that does everything low-level itself and involving a separate slice.

[hadess]

This API is currently in use by both gnome and KDE library code when spawning new apps.

In terms of examples /within/ applications gnome's VTE is the only example I can think of. Currently that does everything low-level itself and involving a separate slice.

What applications do you hope to port to that API? It might be useful to first port applications to use a simplified API (which might or might not involve adding said API to GLib/Qt/etc., is that already started?) and then make that API available to sandboxed applications through the portal.

(I should add that I say "might be useful" in the British sense of the term, I mean "absolutely required")

[benzea]

What applications do you hope to port to that API? It might be useful to first port applications to use a simplified API (which might or might not involve adding said API to GLib/Qt/etc., is that already started?) and then make that API available to sandboxed applications through the portal.

Most likely this will mainly be browsers. There are existing APIs in the form of the kernel APIs obviously. These are already in use by e.g. cgroupify (part of uresourced) which splits browser processes into separate cgroups on F34 so that systemd-oomd does not wreck havoc.

The main questoin here isn't the API itself. The question here is whether we want to use cgroup delegation to solve this problem. And, possibly whether xattrs as signalling mechanism is a good idea (for which we have prior art in systemd-oomd and in Nishal's work for gnome-shell/uresourced integration).

Though, even if we decided for a different approach, this rather simple API could likely stay the same even!

[hadess]

The main questoin here isn't the API itself.

This is pretty much the only thing of interest when it comes to xdg-desktop-portal. If there are users of that API that need sandboxing, then there's a need.

From what I can tell, there's no currently no library that wraps it more generically with being an "app spawn" API, and no applications using that API directly. Did I miss something?