kwin_x11 runs indefinitely because Xvnc exits too early

[ivzhh]

I have a server running Fedora 33 with KDE session through Xrdp and I connect to it with RDP from Mac (Microsoft’s RDP) and another Fedora 33 (Remmina). For the past month, I noticed a symptom: if I click “logout” in KDE and RDP session ends. But kwin_x11 keeps running in getTimestamp(), occupying 100% of a core.

TL;DR: kwin_x11 still waits for message from X server but Xvnc is terminated already. kwin_x11 cannot exit event loop to process quit events.

1. How Xrdp works

Xrdp relies on Xrdp-sesman to launch Xvnc and start a X server. A basic process graph is as following:

xrdp-sesman(68415)───xrdp-sesman(70909)─┬─Xvnc(70915)─┬─{Xvnc}(70924)
                                        │             ├─{Xvnc}(70925)
                                        │             ├─{Xvnc}(70926)
                                        │             ├─...
                                        ├─sh(70914)─┬─ssh-agent(71221)
                                        │           └─startkde(71222)───{startkde}(71234)
                                        └─xrdp-chansrv(70954)───{xrdp-chansrv}(70959)

xrdp-sesman waits for end of life of at least two processes: a display (Xvnc) and a window manager (startkde).

2. How startkde works

In my case, startkde is startplasma-x11.The call graph is:

startplasma-x11 -> plasma_session -> kwin_x11

startplasma-x11 calls plasma_session with QProcess and it ends execution based on unregistration of two dubs services: org.kde.ksmserver and org.kde.Shutdown.

plasma_session is more complicated, it runs the following eight jobs in sequence (refer to _second debug), kwin_x11 is one of them:

• kcminit_startup
• kded5
• kwin_x11
• ksmserver
• startup phase 0
• startup phase 1
• restore session jobs
• startup phase 2

3. What’s the exit condition of kwin_x11

It should be KSelectionOwner::lostOwnership. My understanding is that it is triggered by exiting of X server in this case.

4. What’s the problem

When I click logout in KDE, X server ends and display is closed. This should trigger KSelectionOwner::lostOwnership to end kwin_x11. However, kwin_x11 calls getTimestamp from Qt and it is a blocking call. The getTimestamp() works by sending dummy message to X server to get a timestamp. But now the X server is already dead. This blocks the main thread and thus KSelectionOwner::lostOwnership will never be processed.

5. How to solve that?

I add a delay between exit of window manager and termination of Xvnc.

[matt335672]

Hi @ivzhh

You've provided a lot of good information here.

For information, the sequence of events when the session ends should be:-

• startkde exits
• This causes the shell which starts the window manager (70914 in your example) to exit.
• This is picked up by the sesman fork (70909)
• The sesman fork will kill the X server (70915).

The problem here very much seems to be with kwin_x11 as you've identified. This fault may exhibit itself with session managers other than XRDP.

I think you should file a report with KDE in the first instance as this is likely to help the greatest number of people. I don't think making an official change to sesman is something which we should be doing to fix this.

[ivzhh]

Thank you for the reply! Then I will work with kwin first to resolve the issue.

[ivzhh]

KDE upstream provides an update on this problem. So in the future, Xrdp won't have this issue.