Description of problem: When i log out of a plasma session and log in again, at some point the black Plasma splash screen (showing the text "Plasma made by KDE" in the lower right corner) hangs Version-Release number of selected component (if applicable): plasma-desktop-5.15.5-1.fc30.x86_64 How reproducible: Steps to Reproduce: 1. Log in to a plasma session 2. Log out of the session normally 3. Try to log in again Actual results: The black splash screen hangs after around 10 seconds. Until then, the rotor-like dot circle is moving, but then suddenly stops. I have to go to one of the ascii consoles and kill all my processes. Then login works again. Booting also helps of course. But this is not what should be necessary. Expected results: I can login again normally. Additional info: After logging out, there is a lot of processes lingering around. One of them might still hold some kind of lock, the new login tries to obtain: UID PID PPID C STIME TTY TIME CMD u12 29207 16447 0 19:43 tty5 00:00:00 -bash u12 29541 1 0 19:44 ? 00:00:00 /usr/lib/systemd/systemd --user u12 29543 29541 0 19:44 ? 00:00:00 (sd-pam) u12 29628 29541 0 19:44 ? 00:00:00 /usr/bin/dbus-broker-launch --scope user u12 29630 29628 0 19:44 ? 00:00:00 dbus-broker --log 4 --controller 10 --machine-id 042b4f58bfde4f7b95909498b535b0f4 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000 u12 29672 29541 0 19:44 ? 00:00:00 /usr/libexec/imsettings-daemon u12 29675 29541 0 19:44 ? 00:00:00 /usr/libexec/gvfsd u12 29680 29541 0 19:44 ? 00:00:00 /usr/libexec/gvfsd-fuse /run/user/1679/gvfs -f -o big_writes u12 29896 29541 0 19:44 ? 00:00:00 /usr/libexec/dconf-service u12 29902 1 0 19:44 ? 00:00:00 /usr/bin/baloo_file u12 29926 29541 0 19:44 ? 00:00:00 /usr/bin/pulseaudio --daemonize=no u12 29936 1 0 19:44 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent u12 29947 1 0 19:44 ? 00:00:00 /usr/bin/abrt-applet --gapplication-service u12 29950 1 0 19:44 ? 00:00:00 /usr/libexec/deja-dup/deja-dup-monitor u12 29975 29541 0 19:44 ? 00:00:00 /usr/libexec/at-spi-bus-launcher u12 29983 1 0 19:44 ? 00:00:00 /usr/libexec/tracker-miner-fs u12 29992 29975 0 19:44 ? 00:00:00 /usr/bin/dbus-broker-launch --config-file=/usr/share/defaults/at-spi2/accessibility.conf --scope user u12 29995 29541 0 19:44 ? 00:00:00 /usr/libexec/gvfs-udisks2-volume-monitor u12 29998 1 0 19:44 ? 00:00:00 /usr/libexec/tracker-miner-rss u12 30011 29992 0 19:44 ? 00:00:00 dbus-broker --log 4 --controller 9 --machine-id 042b4f58bfde4f7b95909498b535b0f4 --max-bytes 100000000000000 --max-fds 6400000 --max-matches 5000000000 u12 30038 29926 0 19:44 ? 00:00:00 /usr/libexec/pulse/gconf-helper u12 30061 29541 0 19:44 ? 00:00:00 /usr/libexec/gvfs-mtp-volume-monitor u12 30076 29541 0 19:44 ? 00:00:00 /usr/libexec/gconfd-2 u12 30093 29541 0 19:44 ? 00:00:00 /usr/libexec/gvfs-goa-volume-monitor u12 30106 29541 0 19:44 ? 00:00:00 /usr/libexec/goa-daemon u12 30150 29541 0 19:44 ? 00:00:00 /usr/libexec/goa-identity-service u12 30158 29541 0 19:44 ? 00:00:00 /usr/libexec/gvfs-afc-volume-monitor u12 30166 29541 0 19:44 ? 00:00:00 /usr/libexec/gvfs-gphoto2-volume-monitor u12 30196 29541 0 19:44 ? 00:00:00 /usr/lib64/tumbler-1/tumblerd u12 30224 29541 0 19:44 ? 00:00:00 /usr/libexec/bluetooth/obexd u12 30835 29207 0 19:45 tty5 00:00:00 ps -fwwu u12 Probably some of the genious developers has forgotten or never seen or does not consider it necessery or considers it old-fashioned (this is most likely i guess), that a Unix or Unix-like computer is used by several users in several sessions. I guess this does not matter, however: The hardware is a Lenovo T500
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.