Description of problem: AFter logged out from LXQt Panel, I get a black screen with an alone mouse pointer. Workaround is to reboot or at least restart sddm. Version-Release number of selected component (if applicable): lxqt-panel-.10.0-1.fc23.x86_64 lxqt-session-0.10.0-1.fc23.x86_64 sddm-0.13.0-4.fc23.x86_64 How reproducible: yes Steps to Reproduce: 1. login to lxqt session 2. logout 3. Actual results: black screen Expected results: display manager should be shown with possibility to do another login Additional info: not sure what component to blame for sure. Maybe lxqt-session or sddm just crashes?
This is also reproducible when logout from a plasma5 session, using sddm here too. Now it's sddm to blame.
Any relevant sddm log on the journal or any coredump from coredumpctl?
I've never seen sddm get stuck, but session end does sometimes take longer than expected (sometimes up to a minute or 2)
Proposed as a Blocker for 24-beta by Fedora user raphgro using the blocker tracking app because: After logged out from LXQt Panel, I get a black screen with an alone mouse pointer. Workaround is to reboot or at least restart sddm. This is also reproducible when logout from a plasma5 session, using sddm here too. Now it's sddm to blame. Rex Dieter 2016-01-08 19:03:10 CET I've never seen sddm get stuck, but session end does sometimes take longer than expected (sometimes up to a minute or 2)
Just for the record, the appropriate criterion is: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops." SDDM is installed by default on the KDE Live Image (which is blocking), so by that logic I'd say +1 blocker.
An indication of system information when this black screen with a mouse cursor appears are welcome such as: - what processes are running (output of ps auxw) - logind sessions (loginctl list-sessions) - session information for each session (loginctl show-session XX, loginctl session-status XX where XX is the session id) - sddm log from journal - ~/.xsession-errors
(In reply to Stephen Gallagher from comment #5) … > SDDM is installed by default on the KDE Live Image (which is blocking), so > by that logic I'd say +1 blocker. Right. Sorry about not being that clear.
Discussed at 2016-02-29 blocker review meeting: [1]. It was decided to delay the decision: This bug seems to be a blocker, but we want to have a few more people test with Plasma to be more sure of the breadth of impact before we vote on it [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-29/f24-blocker-review.2016-02-29-17.00.html
Discussed at today's blocker review meeting [1]. We decided to punt (delay decision) - we still don't have sufficient info to make a decision here. we will make a decision next week; if there is not sufficient indication by that time that this issue clearly affects a clean F24 KDE install, it will likely be rejected as a blocker [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-07/
In plasma, may be related to http://bugs.kde.org/359611 and https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=8cec5af40a2112b08bbc60e3163037c05ea1e1f4 which reportedly fixes, https://bugreports.qt.io/browse/QTBUG-49870
fyi, plasma-workspace-5.5.5-3 builds include a back-ported fix for the possible dbus deadlock
Just installed Fedora 24 with KDE on virt-manager. I can reproduce the issue, Plasma logout doesn't lead back to the SDDM greeter. However loginctl show-session 1 shows that the session is of class user rather than greeter, and Desktop=KDE. ps auxwww shows a number of Plasma process like kwin_x11, krunner, xsettings-kde, plasmashell --shut-up etc... I think that Plasma is to blame.
loginctl session-status 1 shows sddm-helper (the process that starts the session) and all the Plasma processes. The Plasma processes are not clearly killed on logout.
(In reply to Pier Luigi Fiorini from comment #12) … > I think that Plasma is to blame. Please be aware that I originally tested with LXQt and it runs lxqt-session. There's no Plasma but LXQt is based on Qt5 as well and the user login happens via SDDM.
Could you please check what's running when this happens? Without session information is impossible to understand what's going on.
(In reply to Pier Luigi Fiorini from comment #15) > Could you please check what's running when this happens? > Without session information is impossible to understand what's going on. I checked, there's no lxqt* related process running when the screen went black after user's clicked and confirmed to logout.
Can't reproduce with LXQt. * LXQt is now installed on the F24 virtual machine that was created yesterday with: dnf install @lxqt * Restarted SDDM to have the sessions list updated. * Logged in on LXQt for the first time * Logout * SDDM greeter shows up after a couple of seconds
plasma-workspace-5.5.5-4.fc24 qt5-qtbase-5.6.0-0.41.rc.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-13bc6572ac
Discussed at today's blocker review meeting [1]. Decided to split from this bug - the new bug is bug 1317618 and is AcceptedBlocker (Alpha) - per comment 12 it appears there is a bug preventing log out in a clean F24 KDE install from working, that bug is accepted as a blocker. We agree that a new report will be filed to separate the KDE case from the lxqt case and the new KDE bug will be the blocker. This existing bug is kept for dealing with LXQt issue. [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-14/ Please note that the update from comment 18 needs to be adjusted to mark fixing bug 1317618, thanks.
plasma-workspace-5.5.5-4.fc24, qt5-qtbase-5.6.0-0.41.rc.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-13bc6572ac
plasma-workspace-5.5.5-4.fc24, qt5-qtbase-5.6.0-0.41.rc.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.