Bug 1939291

Summary:	Cannot override $KDEWM
Product:	[Fedora] Fedora	Reporter:	Kevin Knapp <kbknapp>
Component:	plasma-workspace	Assignee:	KDE SIG <kde-sig>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	34	CC:	bblock, dietrich.moerman, jgrulich, kde-sig, me, rdieter, than, tjuberg
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-12 14:49:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kevin Knapp 2021-03-15 23:57:55 UTC

Description of problem:

`$KDEWM` cannot be overridden. `kwin_x11` seems to start unconditionally (from the `plasma-kwin_x11.service` unit?

Version-Release number of selected component (if applicable): 34

How reproducible: Easy (deterministic)

Steps to Reproduce:
1. Install Fedora 34 KDE Spin
2. Install another WM (such as i3)
3. Set the env var `KDEWM=/usr/bin/i3` before session login (can be accomplished by placing a shell script setting this var in `~/.config/plasma-workspace/env/i3.sh`

Actual results:

Other WM (i.e. such as `i3`) cannot start due to `kwin_x11` already running.

Expected results: `kwin_x11` should not be started, and `KDEWM` should be honored.

Additional info:

This works as expected in Fedora 33, as well as up to date rolling releases such as Arch with the latest Plasma 5. I.e. it's not due to too new a Plasma desktop.

I have also tried masking `plasma-kwin_x11.service`, yet `kwin_x11` is *still* started somehow yet I cannot figure out where it's started from.

Comment 1 Rex Dieter 2021-04-02 13:46:59 UTC

I recommend you report this upstream to bugs.kde.org

Without their help/guidance, I doubt fedora can support this non-standard configuration.

Comment 2 Rex Dieter 2021-04-02 13:49:33 UTC

Also possibly a side-effect of moving towards using systemd user sessions, to confirm, edit
/etc/xdg/startkderc
and set
systemdBoot=false

and retest

Comment 3 Rex Dieter 2021-04-02 13:50:17 UTC

Triage to plasma-workspace component

Comment 4 Kevin Knapp 2021-04-02 13:58:53 UTC

I'll test that out and report back after work today. Thanks!

Comment 5 Kevin Knapp 2021-04-04 17:18:08 UTC

Sorry for the delayed response! Using
systemdBoot=false
Does in fact fix the issue.

Comment 6 Thomas Juberg 2021-05-17 23:06:30 UTC

Thank you for this workaround.

Given that F34 has moved to systemd user sessions which breaks Plasma for anyone using a different WM ( https://userbase.kde.org/Tutorials/Using_Other_Window_Managers_with_Plasma )
Is setting systemdBoot=false likely to cause any other side effects or can this be safely be used as a workaround?

Comment 7 Kevin Knapp 2021-05-18 00:17:06 UTC

I've been using this workaround on my daily machine since it was suggested and I tested it over a month ago and haven't noticed any adverse affects or needing to fix anything else. Perhaps there is something under the covers that isn't working at it's best, but I haven't noticed anything.

Comment 8 Benjamin Block 2021-05-25 17:33:32 UTC

Just FYI, I found an other workaround, where you don't have to disable the systemd user session management for KDE.

You can mask `plasma-kwin_x11.service`:
    systemctl --user mask plasma-kwin_x11.service

Then you need to create a service file for i3 to start instead (the content is basically copied from `/usr/lib/systemd/user/plasma-kwin_x11.service`):
    cat > ~/.config/systemd/user/i3.service <<-END
    [Unit]
    Description=i3 Window Manager
    Wants=plasma-kcminit.service
    PartOf=graphical-session.target
    
    [Service]
    ExecStart=/usr/bin/i3
    Slice=session.slice
    Restart=on-failure
    END

And finally add a `wants` relation to that new file for the `plasma-workspace`:
    systemctl --user daemon-reload
    systemctl --user add-wants plasma-workspace i3.service

That works for me, as it used to. The `$KDEEM` variable thing is not necessary with that AFAICT.

The only thing that might be a problem I've seen so far is, all application started via i3/demnu become a child of the `i3.service` in systemd's ressource management. Like so (you see firefox as child for example):
    .....
    │ ├─i3.service 
    │ │ ├─41369 /usr/bin/i3
    │ │ ├─41392 i3bar --bar_id=bar-0 --socket=/run/user/1000/i3/ipc-socket.00000
    │ │ ├─41403 i3status
    │ │ ├─42123 /usr/bin/alacritty
    │ │ ├─42129 /bin/bash
    │ │ ├─43098 /usr/bin/alacritty
    │ │ ├─43104 /bin/bash
    │ │ ├─43247 /usr/bin/alacritty
    │ │ ├─43253 /bin/bash
    │ │ ├─43624 /usr/lib64/firefox/firefox -P default
    │ │ ├─49047 /usr/bin/alacritty
    │ │ ├─49053 /bin/bash
    │ │ ├─49509 systemctl --user status
    │ │ └─49510 vim -
    .....

That might not be that bad, but because `i3.service` is a child of `session.slice`, and that has gets special ressource allocations from `uresourced.service`, it might have some implications on ressources. Not entirely sure, sorry.

Comment 9 Kevin Knapp 2021-10-07 16:49:16 UTC

As an update, with Fedora 35 (beta) the old way of setting KDEWM no longer works at all. The final solution listed by Benjamin Block is the only way I've been able to get this to work. I'm not sure exactly why the old way stopped working, I'm thinking it could have to do with this commit: https://github.com/KDE/plasma-workspace/commit/554a4f9c48af90c1cf59bd5872b87b230b1c5e71 due to errors and warnings I see listed in the systemd journal, but I'm not positive. Also being that I have a working solution from Mr. Block it doesn't concern me as much.

Comment 10 Rex Dieter 2021-10-12 14:49:09 UTC

I'll go ahead and close this WONTFIX (for lack of better resolution), as this is something we (fedora) cannot support.