https://bugs.kde.org/show_bug.cgi?id=521080
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- I was also bitten by this behavior, because it prevents commands such as systemd-run from doing its job: $ systemd-run --user --scope sleep 1234 Running as unit: run-p11540-i7006.scope; invocation ID: 3d1c64881bf34c8783971ee4c1913c1c $ cat /proc/$(pgrep --full "sleep 1234")/cgroup # run from another terminal 0::/user.slice/user-1000.slice/[email protected]/app.slice/app-org.kde.konsole-11511.scope/tab(11523).scope Closer monitoring shows that the command indeed starts in the intended cgroup but is seized shortly afterwards. The expected behavior, run from e.g. xterm: $ systemd-run --user --scope sleep 1234 Running as unit: run-p11912-i11162.scope; invocation ID: e05c5bda76c54ef395c7bb5ed4ba796f $ cat /proc/$(pgrep --full "sleep 1234")/cgroup # run from another terminal 0::/user.slice/user-1000.slice/[email protected]/app.slice/run-p11912-i11162.scope As I haven't seen a way to opt-out of this "cgroup grabbing", I am currently stuck running an older version of Konsole for such systemd-run commands. :-/ A quick search revealed that this problem might have been introduced as a consequence to handling situations as described in * https://discuss.kde.org/t/konsole-and-yakuake-are-killed-when-a-cli-program-runs-out-of-memory/10203 , * the bug 480884 it mentions, and * also the other linked discuss thread. I can see how the idea behind a cgroup per Konsole tab helps in those cases. However, the way it seems to be implemented is rather unfortunate at the moment as it cleary defies user management of cgroups. (Konsole: 26.04.3, KDE Frameworks: 6.28.0, Qt: Using 6.11.1 and built against 6.11.1, Arch Linux (Xcb), Build ABI: x86_64-little_endian-lp64 Kernel: linux 7.1.5-arch1-1) -- You are receiving this mail because: You are watching all bug changes.
