Bug 1787230
| Summary: | Logging out of KDE Plasma and logging in does not work | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Albert Flügel <af> |
| Component: | plasma-desktop | Assignee: | KDE SIG <kde-sig> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 31 | CC: | butirsky, carmenfdezb, eugenemah, gilboad, jgrulich, kde-sig, me, michel.morisot, m.lincetto, nate, ol+redhat, rdieter, than |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-24 16:54:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Albert Flügel
2020-01-01 19:01:07 UTC
Looks like there is a problem with dbus-broker.
Here's what to do to reproduce the error.
1. Enable lingering for your user: "loginctl enable-linger $USER"
2. Log in on your console using plasma session (display manager does not matter).
3. Log out.
4. Log in again using plasma session.
As a result, you get stuck login: you see default wallpaper and nothing's happening for a long time.
However, when you log in using ssh (or on text console) and stop dbus-broker.service user service ("systemctl --user stop dbus-broker.service") and log in using plasma session again, it works perfectly.
It seems to me that dbus-broker gets stuck or something, and plasma session can't start necessary DBus services.
As a temporary workaround, you can enable another DBus server, dbus-daemon: "systemctl --user enable dbus-daemon.service".
Probably, this bug should be re-categorised to dbus-broker component.
One more thong. The dbus-broker user service (as well as all other user services) is started inside user@$UID.service system service (where $UID is your UID). If you didn't enable lingering, this system service is finished after all sessions for user with this UID are finished, taking down all user services, including dbus-broker. However, there could be some leftover processes from plasma session causing this login session to not really end. If this is the case, this should be reported as a separate bug. Also, user@$UID.service will not end after you log out from your console if you have some other login session, either remote using ssh, or local on text console. Third case when this system service persists until your next console login is if you log in immediately after you logged out: it finishes not immediately, but after some configurable timeout. Either way, if you log in while dbus-broker is already started by your previous plasma session, it gets stuck. I suspect some faulty reasoning in the prior 2 comments. Killing your user dbus session will likely end lingering processes, yes, but I'm not sure you can blame dbus (either implementation) for that, imo. There are two reasons to blame dbus-broker. I've already mentioned the first one in my comment #1: if I enable dbus-deamon instead of dbus-broker, the bug goes away. The second reason is the following. When I look at the journal for the scope of the session that is stuck, I see the following error messages near the beginning: фев 18 00:24:45 infoserver.lv ksmserver[2525746]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") фев 18 00:24:45 infoserver.lv kded5[2525719]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") фев 18 00:24:45 infoserver.lv kaccess[2525727]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.") I don't get these messages in successful session's log. Also, if I kill *all* user services except dbus-broker, plasma session gets stuck. Of course, it could be plasma session doing something that makes dbus-broker to get in some strange state, but dbus-daemon is able to handle this without any problem. Few more interesting observations. 1. After running gnome on x11 session, plasma session doesn't get stuck. This is because gnome session makes dbus-broker restart on logout. 2. After running plasma session, gnomeon x11 session doesn't get stuck. 3. When starting plasma session, there is error message in dbus-broker service log: фев 18 01:01:18 infoserver.lv dbus-broker-launch[2531522]: Updating activation environment failed. No such error produced when starting gnome session. 4. If I restart dbus-broker user service after logging out from plasma session, next plasma session doesn't get stuck. 5. If I stop dbus-broker and activate it using "qdbus --session" from ssh session, next plasma session doesn't get stuck. 6. If I kill plasma session forcefully using "loginctl kill-session" (and don't restart dbus-broker afterwards), next plasma session gets stuck. 7. If I kill stuck plasma session forcefully using "loginctl kill-session", next plasma session still gets stuck. All these observations make me think that dbus-broker gets in some weird state after plasma session. This weird state makes next plasma session stuck, but doesn't affect next gnome session. 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. The problem is observed in Fedora 31 as well. Please update Fedora version number. Once I upgrade to Fedora 32, I'll report whether the problem exists there as well. Still the same with Fedora 31 Also Fedora 32. Have been running into this fairly regularly on my system (Fedora 32) which I was working around by rebooting.
After reading some of the above comments pointing at dbus-broker, restarting the dbus-broker service ("systemctl --user restart dbus-broker") allowed me to log in normally.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 '31'. 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 31 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. The bug is still affecting Fedora 32 and 33 so we should avoid this getting closed for EOL once again, previous reports for the same issue can be found in bug 1708333, bug 1746586. Bug 1787230 filed under SDDM looks like a duplicate, but I guess `plasma-desktop` is the right component. Hello, Solution to try, it seems to have worked for me under fedora 33 sddm --example-config > /etc/sddm.conf in order to fill the file sddm.conf because for me it was empty, next configuration. Must still be tested by other people Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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. |