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.
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” directoryfoo.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 namefoo-bar-baz.servicenot only the regular drop-in directoryfoo-bar-baz.service.d/is searched but also bothfoo-bar-.service.d/andfoo-.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.confoverridesfoo-.service.d/10-override.conf.
With this knowledge, someone adventurous could implement a kcm to set this up or hook it in plasma-system-monitor.
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?
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.)
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?
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.
Very interesting! Now I know how to workaround apps spamming the journal:
https://bugs.kde.org/show_bug.cgi?id=494632
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 