Arch Linux plasma-workspace 5.5.0-4 - /usr/bin/startplasmacompositor and /usr/lib/startplasma and /usr/bin/ksmserver kwin 5.5.0-2 - /usr/bin/kwin_wayland kinit 5.17.0-1 - /usr/lib/kf5/start_kdeinit_wrapper and /usr/bin/kdeinit5 Reproducible: Always Steps to Reproduce: /usr/bin/startplasmacompositor begets /usr/bin/kwin_wayland which begets /usr/lib/startplasma, which gets as far as LD_BIND_NOW=true /usr/lib/kf5/start_kdeinit_wrapper --kded +kcminit_startup which hangs, and blocks the subsequent /usr/bin/ksmserver. Actual Results: The user will see the splash screen and then only a blank desktop with a working mouse. Applications can be started from another terminal, or the session can be killed from another terminal, but only if the user remembers to "Ctrl-Alt-F2". The session cannot be killed from within the Wayland display since the graphic shell never starts. Martin Gräßlin, at https://git.reviewboard.kde.org/r/124293/, 2015 July, mentions explicitly about "startplasma" that "There's still the problem that it needs a patched kdeinit with OOM_PROTECT disabled." And again, at https://plus.google.com/+MartinGräßlin/posts/4T3D7bpZESv Martin mentions "kdeinit dead locks with the oom protection." But, the "/usr/bin/kdeinit5" provided by the recent kinit 5.17.0-1 runs as /usr/bin/kdeinit5 --oom-pipe 4 --kded +kcminit_startup apparently with OOM_PROTECT still enabled, *by default*. We still see in "kinit-5.17.0/src/CMakeLists.txt" set(KDEINIT_OOM_PROTECT 1) which can be seen to apply to src/kdeinit/kinit.cpp, src/start_kdeinit/start_kdeinit.c, and src/start_kdeinit/start_kdeinit_wrapper.c. Soooooo - In order to allow people to run kwin_wayland, for now, until the OOM problem is resolved, it would seem better to choose set(KDEINIT_OOM_PROTECT) to "unset" KDEINIT_OOM_PROTECT, *as the default* - or, at least provide a big fat end-user visible warning about the use of "startplasmacompositor", with respect to being "available" or "not available". Also, KDEINIT_OOM_PROTECT cannot be "unset" from the toplevel CMakeLists.txt, so some changes there would also be useful.
Talking with Martin, there seems to have been some misunderstanding that this OOM issue had something to do with a simultaneously running Xorg server. After testing, this is not the case. A KDE Wayland session will run along side a running Xorg server without problem. And even without a simultaneously running Xorg server, start_kdeinit_wrapper, in /usr/lib/startplasma, *will* hang/freeze unless kinit is compiled with KDEINIT_OOM_PROTECT unset. Also, there is an AUR package, kinit-nooom, which only patches src/kdeinit/kinit.cpp, and does not touch src/start_kdeinit/start_kdeinit.c or src/start_kdeinit/start_kdeinit_wrapper.c, which seems to have worked-around the problem with kinit-5.16. I have not tested that myself. Maybe somebody else would like to look at reset_oom_protect(), at about line 445, and see why this will cause /usr/lib/kf5/start_kdeinit_wrapper to hang?
Git commit 14b9046ad2ae7d4b9e3ffda996b2112fae3690c4 by Martin Gräßlin. Committed on 15/12/2015 at 12:03. Pushed by graesslin into branch 'Plasma/5.5'. Unblock signals in child processes We need to unblock the signals blocked with pthread_sigmask. This caused kdeinit to block, because it relies on SIGUSR1. FIXED-IN: 5.5.1 REVIEW: 126361 M +4 -4 main_wayland.cpp M +1 -1 rules.cpp M +1 -1 useractions.cpp M +18 -0 utils.cpp M +15 -0 utils.h http://commits.kde.org/kwin/14b9046ad2ae7d4b9e3ffda996b2112fae3690c4
One additional patch is required to gain a functioning desktop. The first issue involves kdeinit5 hanging while waiting on programs in the kwin repository/package: https://git.reviewboard.kde.org/r/126361/diff/1?file=422799 That patch will resolve the hang, allowing /usr/lib/startplasma to start ksmserver. But there will still be a blank and unresponsive desktop with a working mouse cursor. To finally start the desktop, apply the patch from the plasma-framework repository/package: https://git.reviewboard.kde.org/r/126320/ Together, those patches should provide a working desktop.