Bug 1939291 - Cannot override $KDEWM
Summary: Cannot override $KDEWM
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-workspace
Version: 34
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-15 23:57 UTC by Kevin Knapp
Modified: 2021-10-12 14:49 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-10-12 14:49:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.