[Bug 1209224] New: xrdp idle issue after updating to TW 20230222
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 Bug ID: 1209224 Summary: xrdp idle issue after updating to TW 20230222 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs@suse.de Reporter: jmscdba@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- After updating to TW 20230222 xrdp was updated from version 0.9.20-5.1.x86_64 to 0.9.20-6.1|x86_64. Starting a new xrdp session from another Linux machine, a Windows 10 machine using MS RDP client, or even from my local machine ( but as a different user ) to the xrdp service on my local machine all connect and work perfectly fine for as long as you want to use them, however, if you let the rdp session sit for a while then when you come back to it the desktop is black and the session is no longer responsive. Originally to recover, I had to kill the processes for the user and also restart the xrdp service. After doing that, then rdp works fine again ( from any of the sources ) until you leave the session sit idle and the problem reocurrs. This did not occur with previous xrdp versions and I am using the stock xrdp configuration without any changes. It was suggested to check /etc/xrdp/sesman.ini to check DisconnectedTimeLimit and IdleTimeLimit but they are both set to the default of 0 which disables disconnection. Yesterday, while trying to debug this further so that I would have more information I came across what I believe is the source of the problem. In System Settings / Power Management / Energy Saving, on the On AC Power Tab, the Screen Energy Saving is checked and it is set to switch off after 10 min. This is the default setting and used by all users, HOWEVER, if I turn that off then xrdp no longer has the issue and the session can be left idle for as long as you like. Looking at my zypper history, I see that powerdevil5 was updated from 5.26.5-1.1 x86_64 to 5.27.0-1.1 x86_64 so I suspect that is the real source of the problem since turning off Screen Energy Saving stops the problem from occurring. Here is my KDE version info: KDE Plasma Version 5.27.0 KDE FrameWorks Version 5.103.0 Qt Version 5.15.8 Please let me know if you need any additional information or logs -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 Joe S <jmscdba@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yfjiang@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 Joe S <jmscdba@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alarrosa@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 Andreas Stieger <Andreas.Stieger@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |yfjiang@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 http://bugzilla.opensuse.org/show_bug.cgi?id=1209224#c1 Yifan Jiang <yfjiang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gnome-bugs@suse.de Assignee|yfjiang@suse.com |yu.daike@suse.com --- Comment #1 from Yifan Jiang <yfjiang@suse.com> ---
In System Settings / Power Management / Energy Saving, on the On AC Power Tab, the Screen Energy Saving is checked and it is set to switch off after 10 min.
...
Looking at my zypper history, I see that powerdevil5 was updated from 5.26.5-1.1 x86_64 to 5.27.0-1.1 x86_64 so I suspect that is the real source of the problem since turning off Screen Energy Saving stops the problem from occurring.
Thanks Joe for the elaborate description. Let me put it in Daike's queue, who is able to drive further analysis. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 http://bugzilla.opensuse.org/show_bug.cgi?id=1209224#c2 --- Comment #2 from Joe S <jmscdba@gmail.com> --- One other useful piece of info I forgot to include The Screen Energy Saving option is turned ON and set to switch off after 10 min and does NOT create a problem when the user is logged on locally to the PC. It only occurs when the user is logged in via RDP to the machine, so the setting only presents the problem when it is ON and the user is logged in via RDP so technically it could be in either or both modules as the source of the problem. It is EASY to test, just login via RDP and set it to only 1 min and then let the session sit and it should occur. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 http://bugzilla.opensuse.org/show_bug.cgi?id=1209224#c3 Daike Yu <yu.daike@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmscdba@gmail.com Flags| |needinfo?(jmscdba@gmail.com | |) --- Comment #3 from Daike Yu <yu.daike@suse.com> --- https://bbs.archlinux.org/viewtopic.php?id=283684 https://www.mail-archive.com/kde-bugs-dist@kde.org/msg786540.html Quick googling gave me some similar report related to xrdp crashes after powerdevil being updated to 5.27.2. There's a DPMS related updated in 5.27.0 changlog, which I suspect might be the cause. Would you mind check the status of xrdp process after the issue occured? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 http://bugzilla.opensuse.org/show_bug.cgi?id=1209224#c4 Joe S <jmscdba@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jmscdba@gmail.com | |) | --- Comment #4 from Joe S <jmscdba@gmail.com> --- Hi Daike,
Would you mind check the status of xrdp process after the issue occured?
Sure no problem, thanks for looking into this. I am still running TW 20230222 which has version 5.27.0 but plan to update TW in the next few days. After machine boots and xrdp starts here is the status systemctl status xrdp ��� xrdp.service - xrdp daemon Loaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; preset: disabled) Active: active (running) since Tue 2023-03-21 09:57:00 EDT; 3min 7s ago Docs: man:xrdp(8) man:xrdp.ini(5) Main PID: 980 (xrdp) Tasks: 3 (limit: 4593) CPU: 1.453s CGroup: /system.slice/xrdp.service ������ 980 /usr/sbin/xrdp --nodaemon ������2480 /usr/sbin/xrdp --nodaemon Then I rdp'd, re-enabled the Energy Saving and set it to 1 minute. After that expired, the problem occurs as initially described. Here is the status of the rdp service after the problem has occurred systemctl status xrdp ��� xrdp.service - xrdp daemon Loaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; preset: disabled) Active: active (running) since Tue 2023-03-21 09:57:00 EDT; 5min ago Docs: man:xrdp(8) man:xrdp.ini(5) Main PID: 980 (xrdp) Tasks: 3 (limit: 4593) CPU: 1.480s CGroup: /system.slice/xrdp.service ������ 980 /usr/sbin/xrdp --nodaemon ������2480 /usr/sbin/xrdp --nodaemon So no issues indicated. As a further test, I tried to rdp to the same machine but using a different login user and that 2nd user can login and everything is working fine. That seems to confirm that xrdp is fine and that the issue is with DPMS change you mentioned. I also did the following test which I think will be helpful 1) restart xrdp 2) rdp as user that has timeout set to 1 minute 3) ssh to machine as user and run journalctl -xef and wait for 1 minute for the issue to occur The user had the following journal entries right when the problem occurs: Mar 21 11:23:55 test kded5[11650]: QDBusAbstractAdaptor: Cannot relay signal KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule* Mar 21 11:23:59 test org_kde_powerdevil[11741]: org.kde.kscreen.dpms: Failed to query DPMS state, cannot trigger Mar 21 11:23:59 test org_kde_powerdevil[11741]: XIO: fatal IO error 0 (Success) on X server ":200.0" Mar 21 11:23:59 test org_kde_powerdevil[11741]: after 318 requests (317 known processed) with 0 events remaining. Mar 21 11:23:59 test org_kde_powerdevil[11741]: The X11 connection broke: Unsupported extension used (code 2) After that occurs the user instance of /usr/libexec/org_kde_powerdevil is no longer running and the session is unusable. Hope that helps! Please let me kow if you need any other information. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209224 http://bugzilla.opensuse.org/show_bug.cgi?id=1209224#c5 --- Comment #5 from Joe S <jmscdba@gmail.com> --- Hi Daike, I updated to TW 20230318 which has plasma 5.27.3 and wanted to give you an update. In this version when the user logs in locally and goes into Settings / Power Management / Energy Saving, they can toggle the Energy Savings checkbox ( the current workaround I was using ) and set the switch off time. Interestly with 20230318, if the user logs off and then I login to that user via RDP and go to Settings / Power Management / Energy Saving, the Energy Savings checkbox and switch off time options do not appear and the first setting is Suspend session. So, I logged on locally as the user and enabled Energy Saving with a switch off time of 1 minute and then I logged off the user and then logged in as the user over RDP and let the RDP session sit for 3 minutes. When I returned to the RDP session after 3 minutes, I found that the problem was NOT occurring now. So possibly with the 5.27.3 update, they removed the setting and ignore the Energy Savings settings when the user is NOT logged in locally. Not sure if that is the *fix* or not. Previously before the bug, when on RDP the screen would blank after that timeout occurred but it was smart enough to recognize it was not a real monitor since it was over RDP. With those changes the RDP session is left on and never blanks the screen like it did previously before this bug occurred. Would be nice if the old behavior still was possible. I will test again after my next TW update. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com