Limit Application Memory Usage with systemd - KDE Blogs

Community Blogs
1

I saw this question on KDE forum about how to limit memory usage of a specific application in KDE, using systemd specifically. I did some research on that.

This is a companion discussion topic for the original entry at https://blogs.kde.org/2024/10/18/limit-application-memory-usage-with-systemd
6 Likes
2

Thanks a ton for researching and writing this!

If anyone is interested in what names exactly can be used for drop-in directories this information can be found in the man page for systemd.unit

Along with a unit file foo.service , a “drop-in” directory foo.service.d/ may exist. All files with the suffix ".conf " from this directory will be merged in the alphanumeric order and parsed after the main unit file itself has been parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Each drop-in file must contain appropriate section headers. For instantiated units, this logic will first look for the instance ".d/ " subdirectory (e.g. "foo@bar.service.d/ ") and read its ".conf " files, followed by the template ".d/ " subdirectory (e.g. "foo@.service.d/ ") and the “.conf " files there. Moreover for unit names containing dashes (”- "), the set of directories generated by repeatedly truncating the unit name after all dashes is searched too. Specifically, for a unit name foo-bar-baz.service not only the regular drop-in directory foo-bar-baz.service.d/ is searched but also both foo-bar-.service.d/ and foo-.service.d/ . This is useful for defining common drop-ins for a set of related units, whose names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose systematic naming structure is built around dashes as component separators. Note that equally named drop-in files further down the prefix hierarchy override those further up, i.e. foo-bar-.service.d/10-override.conf overrides foo-.service.d/10-override.conf .

2 Likes
3

With this knowledge, someone adventurous could implement a kcm to set this up or hook it in plasma-system-monitor.

3 Likes
5

As these transient .service files are being generated from .desktop files (with the information on source file recorded as SourcePath=/usr/share/applications/org.kde.konsole.desktop entry in the service file for instance) I was hoping there is some mechanism to write systemd directives directly in these .desktop files (for instance something like X-systemd-MemoryHigh=2G) and have them be copied into generated .service files but there’s no such mechanism as it turns out.
I’m wondering if it would make anything easier/better than relying on systemd drop-in directories?

6

The systemd drop-in is actually nicer than desktop files. With desktop files, your modified file will be copied to ~/.local/share/applications, and if the original file in /usr/share/applications gets updated, the copy won’t be updated, and you won’t know.

I had some desktop file copies setting environment variables like GDK_SCALE. And I’m using systemd drop-ins instead now.

(It would be nice if we have drop-ins for desktop files, dbus service files, etc.)

7

Do you mean I’m supposed to copy the file myself and make modifications to the copy and leave the original file unmodified? Is this documented somewhere?

8

The menu editor (on right clicking on an icon and “Edit App”) will do that for you automatically. It has to be done this way, because you don’t have write permission under /usr.

9

Very interesting! Now I know how to workaround apps spamming the journal:
https://bugs.kde.org/show_bug.cgi?id=494632

1 Like
10

Great work, OP. I feel like cgroups is a very powerful and useful tool that’s largely unknown.

Quick suggestion related to this: Try systemctl set-property if you want to do this programmatically (eg with a script), as a one-off, or without using a drop-in. For the big nerds: You can set it with dbus, or the C API, too.

Also, the MemoryMax property might be useful for those who need to set a hard limit to memory usage: systemd.resource-control

And you can also limit all kinds of helpful things like this - CPU and swap are prime candidates :slight_smile:

11

There’s a usability problem here caused by KDE escaping dash (“-”) character in .desktop file name when creating transient systemd units.
For example, I have a file ~/.local/share/applications/jetbrains-pycharm-2024.3.desktop for which KDE creates systemd transient unit named
app-jetbrains\x2dpycharm\x2d2024.3@<some-id>.service. This prevents using directories named ~/.config/systemd/user/app-jetbrains-.service.d or ~/.config/systemd/user/app-jetbrains-pycharm-.service.d for overriding unit’s settings. Only directory with full .dektop’s file name works which is inconvenient as it makes it necessary to change overriding directory name when any of the .desktop file name changes (for instance version).

I discovered this trying to create overriding directory for PyCharm which would not depend on application’s version.

For this reason I think KDE should not escape dash characters when creating transient systemd units.

12

Looking at the code: src/gui/systemd/systemdprocessrunner.cpp · master · Frameworks / KIO · GitLab

This follows Desktop Environment Integration

If no application ID is available, the launcher should generate a reasonable name when possible (e.g. using basename(argv[0])). This name must not contain a - character.

// Only alphanum, ‘:’ and ‘_’ allowed in systemd unit names
from KProcessRunner::escapeUnitName

- are reserved for systemd use as a separator here.
Use ‘.’ instead in your .desktop file name: jetbrains.pycharm.2024.3.desktop.

Following xdg desktop entry specification

and D-Bus Specification

  • Each element must only contain the ASCII characters “[A-Z][a-z][0-9]_” and must not begin with a digit.

That excludes ‘-’.

1 Like
13

Thanks for your detailed comment!

Please notice that Desktop Environment Integration forbids dash in ApplicationID specifically and not in the whole unit name where it even encourages one as seen in suggested schemes.

I think what’s missing is to allow for more fine grained scheme here:

Application units should follow the scheme app[-<launcher>]-<ApplicationID>[@<RANDOM>].service or app[-<launcher>]-<ApplicationID>-<RANDOM>.scope

Desktops should be allowed to insert any number of dash delimited names between <launcher> and <ApplicationID>.

xdg desktop entry specification allows dash:

This means that it is a sequence of non-empty elements separated by dots (U+002E FULL STOP), none of which starts with a digit, and each of which contains only characters from the set [A-Za-z0-9-_] : ASCII letters, digits, dash (U+002D HYPHEN-MINUS) and underscore (U+005F LOW LINE).

14

The application ID can be retrieved by stripping the prefix and postfix. This in turn should map to the corresponding .desktop file when available.

Each element must only contain the ASCII characters “[A-Z][a-z][0-9]_” and must not begin with a digit.

Regardless systemd does not allow ‘-’ to reserve it for its own logic.
It restricts a bit the source spec.

15

I asked if escaping of all dashes is really mandated by the specification at systemd-devel mailing list here [systemd-devel] XDG standardization for applications – allow using dash delimited names in application's unit name

16

There is also:

 Note that the hyphen ('-') character is allowed in bus names but not in interface names. It is also problematic or not allowed in various specifications and APIs that refer to D-Bus, such as Flatpak application IDs, the DBusActivatable interface in the Desktop Entry Specification, and the convention that an application's "main" interface and object path resemble its bus name. To avoid situations that require special-case handling, it is recommended that new D-Bus names consistently replace hyphens with underscores.

From D-Bus Specification

Which the xdg entry specification builds upon.

This does not seem like a good use of everybody’s time.

Surely there are more important things to take care of.

I mean replacing ‘-’ with ‘.’ does work, right ?
.desktop files are user-editable, you can copy the jetbrains-pycharm-2024.2.desktop to ~/.local/share/applications/jetbrains.pycharm.2024.2.desktop

And you can escape ‘/’ in the path to apply an override conf to your app:

$ mkdir "app-jetbrains\\x2dpycharm\\x2d2024.2"
mkdir: création du répertoire 'app-jetbrains\x2dpycharm\x2d2024.2'
$ ls
'app-jetbrains\x2dpycharm\x2d2024.2'

Not sure it would work as expected but worth trying.

17

Very interesting! Now I know how to workaround apps spamming the journal:

I was looking at the bug there about the spamming the journal, I didn’t understand the post about the logs getting so big they take hours to open. I thought journald always rotates the journals with a time/size limit so that could not happen.

18

Note that the hyphen (‘-’) character is allowed in bus names but not in interface names.

Do you know if this poses any problem in this case?
What D-BUS interface is used here (by the mechanism running applications using systemd transient unit) specifically?

This does not seem like a good use of everybody’s time.
Surely there are more important things to take care of.

It’s sad and disheartening to read this. Please note that I’m investing here my free time hoping to make KDE better for me and everybody else.

I mean replacing ‘-’ with ‘.’ does work, right ?

There is no need to even replace dash with period as escaping the dash with \x2d and creating drop-in directory with the full name of .desktop file (as you shown) works.
The problem is that this does not allow for convenient drop-in directories which would affect subsets of applications like ~/.config/systemd/user/app-jetbrains-.service.d or ~/.config/systemd/user/app-jetbrains-pycharm-.service.d which I had already described in this topic earlier and which I called a usability problem.
I shouldn’t be forced to change drop-in directory name when I update PyCharm from version 2024.2 to 2024.3. I want settings in the drop-in directory to affect PyCharm no matter what version or versions I have currently installed.

19

Following Lennart’s request in systemd-devel mailing list topic, I raised XDG standardization for applications – allow using dash delimited names in application's unit name · Issue #36614 · systemd/systemd · GitHub.
Lennart asked to CC the right people from the two big desktops there so if you know anyone interested/responsible for this on KDE/Gnome side please let them know about that Github’s issue.

20

The issue is that those apps don’t provide a .desktop file compatible with systemd, in the first place. Ignoring its requirement probably. I remember some apps with such issues that simply changed their filename, I can’t remember which.
And include the version in the .desktop file name is a bad pattern Imo, that no regular Linux application does.
Both issues are jetbrains responsibility.

Those are proprietary applications AFAICT but you could report a bug for them as well.

21

PyCharm does not provide .desktop file at all. I must have created them myself.

Then how do you suggest naming .desktop files for two or more versions of the same app if not by including their versions as part of filenames?

Most of the time one has only one version of application and then there is no problem. But the scheme should be versatile enough to also handle the case of multiple versions of one application.