[REQUEST] systemd based cgroup management

[LaserEyess]

Before opening a feature request

• I checked the next branch to see if the feature has already been implemented
• I searched existing reports to see if it is already requested.

What is the user problem or growth opportunity you want to see solved?

Prominent DEs (GNOME, KDE) have launchers that use systemd's desktop environment integration to place launched applications/services into their own service/scope so that they get all of the benefits of cgroup management. Rofi should natively enable this functionality.

There is "support" for doing this integration with systemd-run in rofi, but it is very limited and has issues (#2048).

How do you know that this problem exists today? Why is this important?

This is extremely important for features like OOM (systemd-oomd) which work at the cgroup level, and will cull based on that alone, not processes. Cgroups are also advantageous for proper desktop resource allocation and preventing things such as DoS.

Who will benefit from it?

Anyone who uses rofi with systemd on linux (a plurality most likely?) will benefit from this.

Rofi version (rofi -v)

Version: 2.0.0-dirty (Installed from Arch's repository)

Configuration

I don't currently have any configuration, it is all the defaults of 2.0.0

Additional information

I have seen the other issues on this (#1751, #2048) and I want to clarify that I don't want to write a shell wrapper to do this, I want to do it natively (i.e., in C, using dbus calls). Rofi has all of the information it needs to make this work, trying to shoehorn it into shell/env parsing just makes a mess.

I would be willing to work on this since it is a rather large change. It is "simple" to do using gdbus, you just have to call the StartTransientUnit method on the user session bus. Using the guidelines given on this page you would simply launch a unit as app-rofi-$appid@$RANDOM.service and then systemd would take care of everything else. There's probably an argument to put things into app.slice as well, and expose some way for customizing launching. But I think that's a bit out of scope.

[DaveDavenport]

I've asked multiple times if this could be done using dbus as to me that is the cleaner solution? But I never got an reaction. I tried searching for it, but never found a good description of how to do it.

A patch would be very welcome.

[LaserEyess]

The docs aren't particularly enlightening. I just looked at the source code for systemd-run to see how it works. The rofi solution would not be as complex or elaborate, you would only need a subset of the functionality provided.

I'm certainly willing to help, but I'm not familiar with the code base so I don't know the best way to go about implementing this. Would it be a separate mode? Some #idfef'ing in source/mode/drun.c?

[DaveDavenport]

Do we need more then an executable name? (information from f.e. the desktop file) then it probably should be added to modes/drun.c (here also lives the DBusActivatable hack). If it is more generic, we can add it to helper.c where the current launching code lives.

[DaveDavenport]

https://github.com/davatorium/rofi/blob/next/source/helper.c#L1047

https://github.com/davatorium/rofi/blob/next/source/modes/drun.c#L376

[LaserEyess]

In theory we just need the app ID as well as whatever is on the Exec= line. But I'll try hacking on rofi and see how far I get and what obstacles I run into.

[DADA30000]

Do we need more then an executable name? (information from f.e. the desktop file) then it probably should be added to modes/drun.c (here also lives the DBusActivatable hack). If it is more generic, we can add it to helper.c where the current launching code lives.

hey, about that DBusActivatable hack, it currently ignores -run-command and other things, and I can't wrap some apps that use DBusActivatable into uwsm graphical slice
EDIT: ah, nvm, I'm dumb, sorry, found the DBusActivatable: false; thing