Bug 1725933 - F32 KDE spin - KDE logout ofetn hangs indefinitely
Summary: F32 KDE spin - KDE logout ofetn hangs indefinitely
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: sddm
Version: 32
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL: https://github.com/sddm/sddm/issues/1034
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-01 18:57 UTC by Patrick Dubois
Modified: 2021-05-25 17:08 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1583793
Environment:
Last Closed: 2021-05-25 17:08:33 UTC
Type: ---


Attachments (Terms of Use)

Description Patrick Dubois 2019-07-01 18:57:42 UTC
+++ This bug was initially created as a clone of Bug #1583793 +++

Description of problem:

Following a fresh install of Fedora 30, KDE logout hangs indefinitely. Issue persists after a full package upgrade.

Version-Release number of selected component (if applicable): 
sddm-kcm-5.15.5-1.fc30.x86_64
sddm-0.18.1-2.fc30.x86_64
sddm-breeze-5.15.5-1.fc30.noarch

How reproducible:

I am satisfied it is a timing issue, so mileage may vary.

Steps to Reproduce:
1. Install F30 KDE spin to disk
2. Update packages (dnf update)
3. Login to KDE, do stuff, logout.

Actual results:
Logout hangs indefinitely

Expected results:
Logout completed and SDDM greeter is restarted.

Additional info:

After logout, sddm-helper process is still running even though startkde script has terminated. It leaves a bunch of other session processes active too.

Same results after rebuilding sddm package from source.

After applying patch:
--- sddm-0.17.0-old/src/helper/HelperApp.cpp    2017-12-05 16:00:16.000000000 +0000
+++ sddm-0.17.0-new/src/helper/HelperApp.cpp    2018-05-29 16:49:44.270509954 +0100
@@ -235,6 +235,7 @@
     }

     void HelperApp::sessionOpened(bool success) {
+       qInfo() << "HelperApp::sessionOpened: enter";
         Msg m = Msg::MSG_UNKNOWN;
         SafeDataStream str(m_socket);
         str << Msg::SESSION_STATUS << success;
@@ -244,6 +245,7 @@
         if (m != SESSION_STATUS) {
             qCritical() << "Received a wrong opcode instead of SESSION_STATUS:" << m;
         }
+       qInfo() << "HelperApp::sessionOpened: exit";
     }

     UserSession *HelperApp::session() {

Messages after logout has hung contain only "HelperApp::sessionOpened: enter" (i.e. not the exit message).

Applying additional patch:
--- sddm-0.17.0-old/src/auth/Auth.cpp   2017-12-05 16:00:16.000000000 +0000
+++ sddm-0.17.0-new/src/auth/Auth.cpp   2018-05-29 17:07:06.315543046 +0100
@@ -191,11 +191,13 @@
                 break;
             }
             case SESSION_STATUS: {
+               qInfo() << "Auth::Private::dataPending: rx SESSION_STATUS";
                 bool status;
                 str >> status;
                 Q_EMIT auth->session(status);
                 str.reset();
                 str << SESSION_STATUS;
+               qInfo() << "Auth::Private::dataPending: tx SESSION_STATUS";
                 str.send();
                 break;
             }

Messages still only show "HelperApp::sessionOpened: enter".

Applying patch:
--- sddm-0.17.0-old/src/auth/Auth.cpp   2017-12-05 16:00:16.000000000 +0000
+++ sddm-0.17.0-new/src/auth/Auth.cpp   2018-05-29 17:16:18.476962930 +0100
@@ -163,6 +163,7 @@
                 break;
             }
             case INFO: {
+               qInfo() << "Auth::Private::dataPending: rx INFO";
                 QString message;
                 Info type = INFO_NONE;
                 str >> message >> type;
@@ -176,6 +177,7 @@
                 break;
             }
             case AUTHENTICATED: {
+               qInfo() << "Auth::Private::dataPending: rx AUTHENTICATED";
                 QString user;
                 str >> user;
                 if (!user.isEmpty()) {
@@ -183,6 +185,7 @@
                     Q_EMIT auth->authentication(user, true);
                     str.reset();
                     str << AUTHENTICATED << environment << cookie;
+                   qInfo() << "Auth::Private::dataPending: tx AUTHENTICATED";
                     str.send();
                 }
                 else {
@@ -191,11 +194,13 @@
                 break;
             }
             case SESSION_STATUS: {
+               qInfo() << "Auth::Private::dataPending: rx SESSION_STATUS";
                 bool status;
                 str >> status;
                 Q_EMIT auth->session(status);
                 str.reset();
                 str << SESSION_STATUS;
+               qInfo() << "Auth::Private::dataPending: tx SESSION_STATUS";
                 str.send();
                 break;
             }

Now logout succeeds, sddm-helper terminates and fresh greeter displayed. Log show:
May 29 17:18:33 localhost.localdomain sddm[12507]: Auth::Private::dataPending: rx INFO
May 29 17:18:33 localhost.localdomain sddm[12507]: Authentication information: "Last failed login: Tue May 29 16:53:13 BST 2018"
May 29 17:18:33 localhost.localdomain sddm[12507]: Auth::Private::dataPending: rx INFO
May 29 17:18:33 localhost.localdomain sddm[12507]: Authentication information: "There were 12 failed login attempts since the last successful login."
May 29 17:18:33 localhost.localdomain sddm-helper[12590]: Starting: "/etc/X11/xinit/Xsession \"/usr/bin/startkde\""
May 29 17:18:33 localhost.localdomain sddm-helper[12590]: HelperApp::sessionOpened: enter
May 29 17:18:33 localhost.localdomain sddm[12507]: Auth::Private::dataPending: rx SESSION_STATUS
May 29 17:18:33 localhost.localdomain sddm[12507]: Auth::Private::dataPending: tx SESSION_STATUS
May 29 17:18:33 localhost.localdomain sddm-helper[12590]: HelperApp::sessionOpened: exit

Restoring the original Auth.cpp and apply the following patch:
--- sddm-0.17.0-old/src/auth/Auth.cpp   2017-12-05 16:00:16.000000000 +0000
+++ sddm-0.17.0-new/src/auth/Auth.cpp   2018-05-29 17:24:37.965392094 +0100
@@ -191,6 +191,7 @@
                 break;
             }
             case SESSION_STATUS: {
+               usleep(1000);
                 bool status;
                 str >> status;
                 Q_EMIT auth->session(status);

Same result, logout works as above.

All indications point to timing issue, although it is way beyond me to figure where and how. I can only hope the big boys can get to the bottom of it.

--- Additional comment from Iestyn Elfick on 2018-05-29 17:28:54 UTC ---

Also reported here: https://github.com/sddm/sddm/issues/1034

--- Additional comment from Rex Dieter on 2018-05-29 18:14:54 UTC ---

Thanks for the upstream bug report, that's the best place to address this.

--- Additional comment from Raphael Groner on 2018-05-30 17:36:18 UTC ---

** Please ignore this comment. Test for External Bug Tracker GitHub.

--- Additional comment from Alexander on 2019-04-24 15:57:10 UTC ---

I see this in 29 and 30 beta.
After installing 29 from spin, I created additional users with "useradd" and System Settings. They logout into black screen. After killing sddm-helper, sddm-greater is showing (but some user's processes continue working).
I've installed 30 beta with updates, and at first time didn't see the problem. I thought it good. But after changing SDDM and appearance themes to Breeze, I got this issue again.
First administrator's account, that created during installation, had logout good.
And now, in 29, I changed SDDM theme to Fedora default, my first account can't logout too as other users.
My hardware is easy - Intel-based PC, SSD, without graphics card.

--- Additional comment from Ben Cotton on 2019-05-02 19:18:02 UTC ---

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Ben Cotton on 2019-05-02 19:39:46 UTC ---

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Fred Wells on 2019-05-13 21:34:26 UTC ---

I've been experiencing this issue for some time, going back to F28 at least.   Happens with F29 and now even much more frequently with F30.
As this has been reported for 30 by others as well, can we please change the version to 30?

--- Additional comment from Ben Cotton on 2019-05-28 19:04:28 UTC ---

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 1 Patrick Dubois 2019-07-01 19:00:44 UTC
This has been a persistent problem since at least 2017 and can ruin the user experience for those who use the KDE spin. 
While it is not clear if the problem is with KDE or SDDM it does appear to be a timing issue.    

My apologies if this is a duplicate.

Comment 2 Ben Cotton 2020-04-30 20:33:49 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Fred Wells 2020-05-11 21:43:05 UTC
For what it's worth, it's still ever present on Fedora 32.
IMO, this single bug fundamentally breaks any user experience - over and above almost any other KDE bug.  And yet, nobody seems to take notice of it. 
I suppose the only hope to possibly get any traction on this is to allow this bug to wither and expire and to open a fresh one.

Comment 4 Fred Wells 2020-05-12 03:33:55 UTC
Thank you for extending this to Fedora 32.  Let's hope for someone to pick this up.  I'm happy to provide any necessary debug.

Comment 5 phoebos 2020-10-22 11:10:19 UTC
I've had the same bug on Fedora 32 as well. Ctrl-Alt-F2ing to tty2 and running startx works to create a new session. Manually kill -9ing the tty1 session also stops it successfully.

Comment 6 Fred Wells 2020-10-22 12:57:12 UTC
While the verdict is still out, I do seem to see some improvement on Fedora by disabling the ABRT daemon.

Comment 7 Fred Wells 2020-11-05 00:32:51 UTC
Verdict is in.  Disabling Fedora ABRT daemon had no impact.  :(

Comment 8 Ugo Viti 2021-01-01 16:21:12 UTC
Hi,

I confirm this bug.

Just installed Fedora 33 KDE Spin into a new Dell XPS 13 11th generation.

Only 2 "quick" workaround discovered until now:

1) If you want continue using SDDM when stuck on logout:

a. CTRL-ALT-F2

b. login in Linux console as your username or root

c. run: loginctl terminate-user <username>


2) You can replace SDDM with GDM:

sudo dnf install gdm -y
sudo systemctl disable sddm --now
sudo systemctl enable gdm --now

Kind Regards

Comment 9 Robin Laing 2021-02-11 19:11:38 UTC
This is a problem when running multiple sessions.

For work at home, I run a separate session for personal and work.  In F32, the issue was random when logging out but in F33, it is worse.  

I will have to try the gdm switch next time I do a full shutdown of sessions and see if that happens.

As there are two people now reporting this issue with F33, it should be updated to F33.

From bug report, 
https://bugzilla.redhat.com/show_bug.cgi?id=1861700
Notice that I have also tried with GDM instead of SDDM and see the same.


I would recommend reading this bug as there are some ideas for testing and getting information that I have not seen or heard of before.

https://bugzilla.redhat.com/show_bug.cgi?id=1861700

Comment 10 Fred Wells 2021-03-27 21:10:49 UTC
Replacing nouveau with nVidia graphics drivers seems to have resolved it for me (for now).

Comment 11 Patrick Dubois 2021-04-07 15:56:16 UTC
(In reply to Fred Wells from comment #10)
> Replacing nouveau with nVidia graphics drivers seems to have resolved it for
> me (for now).

I've been running with nVidia drives since the start and logout still fails at least 50% of the time.

Comment 12 Fred Wells 2021-04-08 12:11:27 UTC
(In reply to Patrick Dubois from comment #11)
> (In reply to Fred Wells from comment #10)
> > Replacing nouveau with nVidia graphics drivers seems to have resolved it for
> > me (for now).
> 
> I've been running with nVidia drives since the start and logout still fails
> at least 50% of the time.

Turns out my success was short lived.   It's about 20% failure for me now.

Comment 13 Greg Lappen 2021-04-09 20:02:01 UTC
I have been having this issue on F33 ever since I installed it a couple months ago. I'm seriously considering switching to a different distro. I am on a Dell Inspiron desktop, Intel Graphics, and I never had this issue with other distros. But I've been liking Fedora fine otherwise!

Comment 14 Fedora Program Management 2021-04-29 16:47:30 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Patrick Dubois 2021-05-25 14:49:12 UTC
Interesting update - I continued to see this issue on every logout with Fedora 34 right up to the recent KF5 updates I applied on the 25th of may.   

Since then I have not had a single instance of the logout hanging.   Could this actually be finally resolved ?

Comment 16 Ben Cotton 2021-05-25 17:08:33 UTC
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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