STEPS TO REPRODUCE 1. Run Yakuake from Kickoff 2. Open systemmonitor 3. Go to Applications OBSERVED RESULT Yakuake is not in the list EXPECTED RESULT Yakuake is in the list SOFTWARE/OS VERSIONS KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18 Qt Version: 6.9.2 ADDITIONAL INFORMATION This is presumably because Yakuake is DBus-activatable, which affects the naming pattern of the cgroup
Is this dbus-daemon or dbus-broker? What is the resulting cgroup name?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
(In reply to David Redondo from comment #1) > Is this dbus-daemon or dbus-broker? dbus-broker > What is the resulting cgroup name? dbus-:1.2-org.kde.yakuake@0.service
Ok so when launching a process we normally make sure that apps end up in the correct cgroup. When launching a DBusActivatable=true app we just make the bus call and do nothing. So far what we did was that we added a systemd file for our apps that are dbusactivatable so systemd moves it to a "correct" service name. I looked at gnome-shell and it appears to me that they are not shipping systemd service files for their apps but instead fix up the service afterwards it is launched via dbus.
Long term that's something we could do as well.
I am wrong, the function I was guessing to do this actually noops in the dbus case. usage apps still shows it though, but they have no special case for dbus, I guess the code they do to fetch cgroup works by coincidence https://gitlab.gnome.org/GNOME/gnome-usage/-/blob/main/src/app-item.vala#L113 instead of the mad regex we have that really tries to verify the spec Still I think we should aim to follow spec but we could maybe relax our unit parsing.