Created attachment 1609128 [details] output of 'startx /usr/bin/startkde -- :1 vt4 &>/tmp/kde-failure-log &' Description of problem: The first login to Plasma after boot works correctly, but any attempt at logging in again after logging out from the first session results only in the splash screen for awhile and then a blank screen with only the mouse cursor. This happens for me on the F30 KDE spin livecd also, but not on the Rawhide KDE livecd. Version-Release number of selected component (if applicable): plasma-workspace-5.15.5-1.fc30.x86_64 How reproducible: Always Steps to Reproduce: 1. Reboot computer 2. Login to plasma 3. Logout of plasma 3. Try to log back in to plasma Actual results: Splash screen is shown, eventually goes away leaving a black desktop with only mouse cursor visible Expected results: Plasma session begins and KDE is usable Additional info: If I login to a tty as the user who login fails for, and do `systemctl --user restart dbus` , then I can login again but then as before a second login attempt fails
It does happen that some background services/daemons sometimes do not end immediately on logout. Either wait at least 30 seconds or use logind to enforce all processes end on logout via editing /etc/systemd/logind.conf to include: KillUserProcesses=yes
(In reply to Rex Dieter from comment #1) > It does happen that some background services/daemons sometimes do not end > immediately on logout. Either wait at least 30 seconds or use logind to > enforce all processes end on logout via editing > /etc/systemd/logind.conf to include: > KillUserProcesses=yes Thank you for clearing this up for me. I couldn't use KillUserProcesses=yes in /etc/systemd/logind.conf because it killed my tmux sessions but waiting some time before logging back in works.
I have been able to reproduce this issue on FC31-beta. Please let me know if there is any additional information I can provide to assist in resolving this issue.
This issue exists for me on F31 too. I wonder if it has anything to do with IME or themes. I use the Arc KDE themes and fcitx. This is on a freshly upgraded F31.
The workaround to edit logind config does NOT work for me. When I logout X simply hangs with a mouse cursor. I need to restart sddm from the command line. Something is refusing to get killed on logout. I know KDE has had a problem with zombie processes before but it was a long time ago.
Comment #5 is different, then. In your case, logout never finishes, you never get to login again.
Related issue, bug #1742893 (possibly a dup)
https://bugzilla.redhat.com/show_bug.cgi?id=1742893#c3 Has more detailed info on workarounds, and additional debugging to try
(In reply to Rex Dieter from comment #8) > https://bugzilla.redhat.com/show_bug.cgi?id=1742893#c3 > > Has more detailed info on workarounds, and additional debugging to try I'm also affected. I tried that workarounds. Edit logind.conf seems to not affect the chances of successful relogin. But I'm not sure as this problem isn't reproducible every logout. When I run the command for obtaining my user processes after a logout, it appears a list similar to the ones attached in bug #1742893 , and when trying to login, if there are remaining processes, login is unsuccessful. Trying to obtain the processes list after this bug is reproduced shows a number of plasma processes loaded, and after waiting a long time, more processes are loaded, included the ones on autostart list, but returning in tty1 shows only a mouse over the welcome screen. Using the command to kill my user allows me to relogin successfully again. And also can prevent a failed attempt if ran before it. A problem here is that after logout, the output of loginctl only shows root and sddm users logged, when processes of my user are still active, anyway, loginctl kill-user <user> can actually kill all remaining processes and allow a successful login in any cases. My desktop is themed, I don't know if this has anything to do with the problem. I could reproduce this bug on another desktop with oxygen, which is an official theme. Maybe I should try with Breeze.
Can you list the still-running processes inline in a bugzilla comment? (Attachments are inconvenient and not searchable)
(In reply to Rex Dieter from comment #10) > Can you list the still-running processes inline in a bugzilla comment? > (Attachments are inconvenient and not searchable) Got from ps -aux | grep <username> on tty2 after KDE Plasma logout Fedora (31):- liveuser 1393 0.1 0.0 20576 10704 ? Ss 08:57 0:00 /usr/lib/systemd/systemd --user liveuser 1395 0.0 0.0 46072 5400 ? S 08:57 0:00 (sd-pam) liveuser 1423 0.0 0.0 276616 3648 ? Ss 08:57 0:00 /usr/bin/dbus-broker-launch --scope user liveuser 1424 0.4 0.0 6844 4496 ? S 08:57 0:00 dbus-broker --log 4 --controller 11 --machine-id 0c9eecf9893d439fa847f2881a06c26a --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000 liveuser 1503 0.0 0.0 156040 5508 ? Ssl 08:57 0:00 /usr/libexec/dconf-service liveuser 1576 0.0 0.0 444224 4860 ? Sl 08:57 0:00 /usr/libexec/geoclue-2.0/demos/agent liveuser 1583 0.0 0.1 404056 17924 ? Sl 08:57 0:00 /usr/bin/abrt-applet --gapplication-service liveuser 1687 0.0 0.0 308720 8016 ? Ssl 08:57 0:00 /usr/libexec/at-spi-bus-launcher liveuser 1696 0.0 0.0 268356 3584 ? S 08:57 0:00 /usr/bin/dbus-broker-launch --config-file=/usr/share/defaults/at-spi2/accessibility.conf --scope user liveuser 1700 0.0 0.0 5076 1272 ? S 08:57 0:00 dbus-broker --log 4 --controller 9 --machine-id 0c9eecf9893d439fa847f2881a06c26a --max-bytes 100000000000000 --max-fds 6400000 --max-matches 5000000000 liveuser 1758 0.0 0.0 232808 6232 ? Ss 08:57 0:00 /usr/libexec/gconfd-2 root 1986 0.0 0.0 35136 5880 ? Ss 08:58 0:00 login -- liveuser liveuser 1989 0.0 0.0 226228 5132 tty2 Ss 08:58 0:00 -bash liveuser 2025 0.0 0.0 227348 3616 tty2 R+ 08:59 0:00 ps -aux liveuser 2026 0.0 0.0 215980 824 tty2 R+ 08:59 0:00 grep --color=auto liveuser Kubuntu (19.10) (doesn't have this problem):- kubuntu 1278 0.1 0.0 18400 9640 ? Ss 15:24 0:00 /lib/systemd/systemd --user kubuntu 1279 0.0 0.0 168180 2960 ? S 15:24 0:00 (sd-pam) kubuntu 1312 0.4 0.0 8312 5648 ? Ss 15:24 0:02 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only kubuntu 1385 0.0 0.0 156040 5496 ? Sl 15:24 0:00 /usr/lib/dconf/dconf-service kubuntu 1402 0.1 0.2 268664568 28448 ? SNl 15:24 0:00 /usr/bin/baloo_file kubuntu 1470 0.0 0.0 236860 4924 ? Sl 15:24 0:00 /usr/lib/geoclue-2.0/demos/agent kubuntu 1474 0.0 0.0 308924 8656 ? Sl 15:24 0:00 /usr/lib/at-spi2-core/at-spi-bus-launcher --launch-immediately kubuntu 1487 0.0 0.0 7200 4564 ? S 15:24 0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 kubuntu 1519 0.0 0.0 42928 6608 ? Ss 15:24 0:00 /usr/lib/bluetooth/obexd kubuntu 2386 0.0 0.0 236860 4952 ? Sl 15:26 0:00 /usr/lib/geoclue-2.0/demos/agent kubuntu 2769 0.0 0.0 538436 11932 ? Ssl 15:26 0:00 /usr/libexec/xdg-desktop-portal kubuntu 2773 0.0 0.0 391780 6384 ? Ssl 15:26 0:00 /usr/libexec/xdg-document-portal kubuntu 2776 0.0 0.0 235524 4648 ? Ssl 15:26 0:00 /usr/libexec/xdg-permission-store kubuntu 4011 0.2 0.0 10972 5284 tty2 S 15:30 0:00 -bash kubuntu 4051 0.0 0.0 11768 3484 tty2 R+ 15:31 0:00 ps -aux kubuntu 4052 0.0 0.0 9036 856 tty2 S+ 15:31 0:00 grep --color=auto -i kubuntu
(In reply to Rex Dieter from comment #10) > Can you list the still-running processes inline in a bugzilla comment? > (Attachments are inconvenient and not searchable) List of processes from minutes ago, but the relogin attempt this time was SUCCESSFUL. Maybe it's because I manually closed every background app before I logout? avahi 1065 0.0 0.0 6888 1520 ? Ss 14:27 0:00 avahi-daemon: running [Carlos.local] Carlos 1705 0.0 0.1 20320 4468 ? Ss 14:27 0:00 /usr/lib/systemd/systemd --user Carlos 1773 0.0 0.0 27396 60 ? S 14:27 0:00 (sd-pam) Carlos 16999 0.0 0.0 268404 932 ? Ss 14:28 0:00 /usr/bin/dbus-broker-launch --scope user Carlos 17015 0.0 0.1 8084 4008 ? S 14:28 0:01 dbus-broker --log 4 --controller 10 --machine-id 27dd8ca8afb9456e953590147129cc01 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000 Carlos 17091 0.0 0.0 445096 1576 ? Ssl 14:28 0:00 /usr/libexec/imsettings-daemon Carlos 17123 0.0 0.0 446804 1468 ? Ssl 14:28 0:00 /usr/libexec/gvfsd Carlos 18735 0.0 0.0 158328 1416 ? Ssl 14:28 0:00 /usr/libexec/dconf-service Carlos 19347 0.0 0.0 226804 2212 ? Ss 14:28 0:00 /usr/libexec/gconfd-2 Carlos 20478 0.0 0.0 44952 1408 ? Ss 14:28 0:00 /usr/libexec/bluetooth/obexd Carlos 24151 0.0 0.0 307072 2196 ? Ssl 14:33 0:00 /usr/libexec/at-spi-bus-launcher Carlos 24156 0.0 0.0 270396 520 ? S 14:33 0:00 /usr/bin/dbus-broker-launch --config-file=/usr/share/defaults/at-spi2/accessibility.conf --scope user Carlos 24157 0.0 0.0 7132 992 ? S 14:33 0:00 dbus-broker --log 4 --controller 9 --machine-id 27dd8ca8afb9456e953590147129cc01 --max-bytes 100000000000000 --max-fds 6400000 --max-matches 5000000000 Carlos 24931 0.0 0.0 371392 1036 ? Ssl 14:58 0:00 /usr/libexec/gvfsd-metadata
(In reply to Rex Dieter from comment #10) > Can you list the still-running processes inline in a bugzilla comment? > (Attachments are inconvenient and not searchable) List of processes from a unsuccessful login. It seems to be exactly the same unless for the last process of the succesful one /usr/libexec/gvfsd-metadata which is not present in the failed attempt avahi 1065 0.0 0.0 6888 1716 ? Ss 14:27 0:00 avahi-daemon: running [Carlos.local] Carlos 28061 0.0 0.2 20316 10452 ? Ss 15:25 0:00 /usr/lib/systemd/systemd --user Carlos 28063 0.0 0.0 175136 3728 ? S 15:25 0:00 (sd-pam) Carlos 28096 0.0 0.0 268404 3616 ? Ss 15:25 0:00 /usr/bin/dbus-broker-launch --scope user Carlos 28097 0.3 0.1 7884 5692 ? S 15:25 0:01 dbus-broker --log 4 --controller 10 --machine-id 27dd8ca8afb9456e953590147129cc01 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000 Carlos 28105 0.0 0.1 445144 7644 ? Ssl 15:25 0:00 /usr/libexec/imsettings-daemon Carlos 28108 0.0 0.2 446804 7696 ? Ssl 15:25 0:00 /usr/libexec/gvfsd Carlos 28301 0.0 0.1 158328 5720 ? Ssl 15:25 0:00 /usr/libexec/dconf-service Carlos 28503 0.0 0.1 226772 6360 ? Ss 15:25 0:00 /usr/libexec/gconfd-2 Carlos 28669 0.0 0.1 44952 6592 ? Ss 15:25 0:00 /usr/libexec/bluetooth/obexd Carlos 28987 0.0 0.1 307072 6172 ? Ssl 15:26 0:00 /usr/libexec/at-spi-bus-launcher Carlos 28993 0.0 0.0 270396 3520 ? S 15:26 0:00 /usr/bin/dbus-broker-launch --config-file=/usr/share/defaults/at-spi2/accessibility.conf --scope user Carlos 28994 0.0 0.0 7132 1284 ? S 15:26 0:00 dbus-broker --log 4 --controller 9 --machine-id 27dd8ca8afb9456e953590147129cc01 --max-bytes 100000000000000 --max-fds 6400000 --max-matches 5000000000
Another list from a successful attempt. It's not the same of neither of the two previous. avahi 1065 0.0 0.0 6888 1716 ? Ss 14:27 0:00 avahi-daemon: running [Carlos.local] Carlos 29541 0.0 0.2 20320 10372 ? Ss 15:31 0:00 /usr/lib/systemd/systemd --user Carlos 29543 0.0 0.0 175136 3744 ? S 15:31 0:00 (sd-pam) Carlos 29576 0.0 0.0 268404 3564 ? Ss 15:31 0:00 /usr/bin/dbus-broker-launch --scope user Carlos 29577 0.2 0.1 7900 5476 ? S 15:31 0:01 dbus-broker --log 4 --controller 10 --machine-id 27dd8ca8afb9456e953590147129cc01 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000 Carlos 29585 0.0 0.2 445144 7848 ? Ssl 15:31 0:00 /usr/libexec/imsettings-daemon Carlos 29588 0.0 0.1 446804 7272 ? Ssl 15:31 0:00 /usr/libexec/gvfsd Carlos 29781 0.0 0.1 158328 5552 ? Ssl 15:31 0:00 /usr/libexec/dconf-service Carlos 29972 0.0 0.1 226804 5980 ? Ss 15:31 0:00 /usr/libexec/gconfd-2 Carlos 30116 0.0 0.1 44952 6588 ? Ss 15:31 0:00 /usr/libexec/bluetooth/obexd Carlos 30573 0.0 0.1 307072 6244 ? Ssl 15:35 0:00 /usr/libexec/at-spi-bus-launcher
Can someone test with setting EnvironmentFile=-/etc/locale.conf in the [Service] section of /usr/lib/systemd/system/sddm.conf (or in a copy in /etc/systemd/system/)? It may cause problems with SELinux, which was why it was modified in the first place. You can also add RestartSec=1s for good measure.
(In reply to Saurav Sengupta from comment #15) > Can someone test with setting EnvironmentFile=-/etc/locale.conf in the > [Service] section of /usr/lib/systemd/system/sddm.conf (or in a copy in > /etc/systemd/system/)? It may cause problems with SELinux, which was why it > was modified in the first place. You can also add RestartSec=1s for good > measure. These files doesn't exist in my system.
(In reply to Carlos from comment #16) > (In reply to Saurav Sengupta from comment #15) > > ...setting EnvironmentFile=-/etc/locale.conf in the > > [Service] section of /usr/lib/systemd/system/sddm.conf...? > > These files doesn't exist in my system. From the lists of processes in your comments, I see that your system uses systemd. Run systemctl status sddm.service to find out where the service file is located (it'll be near the top of the output, within parentheses). (It's not in /etc/systemd/system/ by default; I mentioned that in case someone wants to create the customized copy there to avoid disturbing the original.)
(In reply to Saurav Sengupta from comment #17) > (In reply to Carlos from comment #16) > > (In reply to Saurav Sengupta from comment #15) > > > ...setting EnvironmentFile=-/etc/locale.conf in the > > > [Service] section of /usr/lib/systemd/system/sddm.conf...? > > > > These files doesn't exist in my system. > > From the lists of processes in your comments, I see that your system uses > systemd. Run systemctl status sddm.service to find out where the service > file is located (it'll be near the top of the output, within parentheses). > (It's not in /etc/systemd/system/ by default; I mentioned that in case > someone wants to create the customized copy there to avoid disturbing the > original.) Ah, you meant sddm.service, not .conf
(In reply to Saurav Sengupta from comment #17) > (In reply to Carlos from comment #16) > > (In reply to Saurav Sengupta from comment #15) > > > ...setting EnvironmentFile=-/etc/locale.conf in the > > > [Service] section of /usr/lib/systemd/system/sddm.conf...? > > > > These files doesn't exist in my system. > > From the lists of processes in your comments, I see that your system uses > systemd. Run systemctl status sddm.service to find out where the service > file is located (it'll be near the top of the output, within parentheses). > (It's not in /etc/systemd/system/ by default; I mentioned that in case > someone wants to create the customized copy there to avoid disturbing the > original.) There is already a EnvironmentFile=-/etc/sysconfig/sddm on sddm.service. I should add the one to suggest apart or replace it?
(In reply to Carlos from comment #18) > (In reply to Saurav Sengupta from comment #17) > > (In reply to Carlos from comment #16) > > > (In reply to Saurav Sengupta from comment #15) > > > > ...setting EnvironmentFile=-/etc/locale.conf in the > > > > [Service] section of /usr/lib/systemd/system/sddm.conf...? > > > > > > These files doesn't exist in my system. > > > > From the lists of processes in your comments, I see that your system uses > > systemd. Run systemctl status sddm.service to find out where the service > > file is located (it'll be near the top of the output, within parentheses). > > (It's not in /etc/systemd/system/ by default; I mentioned that in case > > someone wants to create the customized copy there to avoid disturbing the > > original.) > > Ah, you meant sddm.service, not .conf Yes, sorry about that, everyone; my mistake. It's sddm.service
(In reply to Carlos from comment #19) > (In reply to Saurav Sengupta from comment #17) > > (In reply to Carlos from comment #16) > > > (In reply to Saurav Sengupta from comment #15) > > > > ...setting EnvironmentFile=-/etc/locale.conf in the > > > > [Service] section of /usr/lib/systemd/system/sddm.conf...? > > > > > > These files doesn't exist in my system. > > > > From the lists of processes in your comments, I see that your system uses > > systemd. Run systemctl status sddm.service to find out where the service > > file is located (it'll be near the top of the output, within parentheses). > > (It's not in /etc/systemd/system/ by default; I mentioned that in case > > someone wants to create the customized copy there to avoid disturbing the > > original.) > > There is already a EnvironmentFile=-/etc/sysconfig/sddm on sddm.service. I > should add the one to suggest apart or replace it? Replace it (change the -/etc/sysconfig/sddm to -/etc/locale.conf). Before doing that, however, make sure that the location of locale.conf is correct. On Fedora (31) it's /etc/locale.conf. On (K)Ubuntu it's /etc/default/locale. Enter the correct location in EnvironmentFile (remember to keep the hyphen (-) sign at the beginning of the path - just change the path after the hyphen).
It would also be better to reboot (restart) the system after the modification instead of just logging out. Another option is to run [sudo] systemctl restart sddm.service (which logs out automatically), but the result wasn't satisfactory on my system.
(In reply to Saurav Sengupta from comment #21) > > Replace it (change the -/etc/sysconfig/sddm to -/etc/locale.conf). Before > doing that, however, make sure that the location of locale.conf is correct. > On Fedora (31) it's /etc/locale.conf. On (K)Ubuntu it's /etc/default/locale. > Enter the correct location in EnvironmentFile (remember to keep the hyphen > (-) sign at the beginning of the path - just change the path after the > hyphen). I wouldn't say this is a valid solution, but I wouldn't say either this doesn't work at all. Could be placebo effect, but I tested it a few times, sometimes logging out with more processes in background and other times with less processes, and the most part of the attempts were succesful. However, I still could reproduce this bug in some contiditions (inmediate login after logout, packagekit searching for updates when tons of other processes were loaded...)
I wouldn't say it's a valid solution either, but this was the main difference I found between Kubuntu and Fedora. You could also try disabling PackageKit (or just KDE Plasma Discover), but that too wouldn't be a 'satisfactory solution' in my opinion.
Did you add RestartSec=1s (comment #15)? Also, try combining it with KillUserProcesses in /etc/systemd/logind.conf.
(In reply to Saurav Sengupta from comment #25) > Did you add RestartSec=1s (comment #15)? Also, try combining it with > KillUserProcesses in /etc/systemd/logind.conf. Yes, I've applied all workarounds suggested xd
Saurav, Can you please provide reasoning and evidence why you think those suggested changes to sddm.service will help in this case? Is it just because kubuntu does that? I do know PackageKit is (should be!) completely unrelated.
I can say with some certainty that if setting in logind.conf: KillUserProcesses=yes doesn't work, then that's a systemd bug in that it's not working as advertised.
(In reply to Rex Dieter from comment #27) > Saurav, > Can you please provide reasoning and evidence why you think those suggested > changes to sddm.service will help in this case? > > Is it just because kubuntu does that? It is not 'just' because Kubuntu does that. In fact, it may not be related at all. However, as per my experience, /etc/sysconfig/sddm only "works around" a couple of bugs which seem to be related to SELinux. If that's the case, then it could be that the problem lies with SELinux, and then, it should be SELinux that should be investigated (if those bugs are not yet fixed). However, after a bit of further investigation, I found the following on Fedora, and made some modifications:- 1. In /etc/sddm.conf, section [X11]:- # Path to a script to execute when stopping the display server #DisplayStopCommand=/etc/sddm/Xstop Uncomment the DisplayStopCommand line. 2. In /etc/sddm/Xstop - referred to in the DisplayStopCommand above (also in /usr/share/sddm/scripts/Xstop, but I don't know whether that's used anywhere):- #!/usr/bin/sh # Xstop - run as root after stopping X Add the following line:- loginctl kill-session `loginctl --no-legend list-sessions | awk '{ print $1 }'` Rebooting after these modifications "seems to" help, but I'm not at all sure whether they're the solution. The reason for my loginctl kill-session addition to Xstop is that if you log out (in the default configuration), then log in to another tty, you'll see that existing sessions are not being killed on logout, for which Xstop seemed to me to be a good candidate (if this works, similar modifications may be needed for Wayland). > I do know PackageKit is (should be!) completely unrelated. Even I think that PackageKit ought to be unrelated. I mentioned it because of comment #23.
By the way, the suggestions in comment #29 may be carried out without following those in comment #15. They seem to be unrelated.
> ... you'll see that existing sessions are not being killed on logout.... This occurs on Kubuntu as well, so I'm even more unsure about this. I'm using Kubuntu as a fallback (because it works correctly), but I think comparing with Neon would serve the purpose better. If the problem occurs on Neon, then most probably Kubuntu is doing something that others aren't. (As far as I could make out, Kubuntu is only configuring NVIDIA drivers on Xstop, etc.) N.B.: One more point: After I log out on a default configuration on Fedora 31, and if I wait a (relatively long) while (and/or switch ttys), I see a message at the top-right corner of the screen:- Could not sync environment to dbus. This is followed by an 'Okay' button, which does nothing.
> I see a message at the top-right corner of the screen:- Sorry, that should be top-left corner of the screen.
loginctl kill-session `loginctl --no-legend list-sessions | awk '{ print $1 }'` will kill any other sessions which might be running (on other ttys). One way to avoid this, provided you are running only one Plasma session (which usually appears to be the case), seems to be loginctl kill-session `loginctl --no-legend | grep -v 'tty' | grep \`whoami\`` (I think more experienced people will know how to figure out the currently running Plasma session), but it still doesn't work for "immediate" login. It seems that we need to wait for a second or two (which should not be a problem in the usual case where there's a password).
We won't be incorporating any hacks like running 'loginctl kill...' anywhere officially (so please don't suggest anyone do that). Besides, that's precisely what KillUserProcesses=yes is supposed to do in a cleaner way.
Did some more testing myself this morning, unfortunately did not learn much new. My findings are below: Xstop does not appear to run when a user logs out (I believe sddm and at least first user session shares the same X server), so that's not a practical option here anyway. I tested with and without KillUserProcesses=yes (changing this value in logind.conf, and rebooting). About 5 attempts each: * Without it, I do see lingering processes on logout, but was never able to reproduce any failed logins. * With it, I did not see any lingering processes on logout, and all re-login attempts were successful (unsurprising).
(In reply to Rex Dieter from comment #34) > We won't be incorporating any hacks like running 'loginctl kill...' anywhere > officially (so please don't suggest anyone do that). Besides, that's > precisely what > KillUserProcesses=yes > is supposed to do in a cleaner way. That was a suggestion for a workaround, not a solution. If KillUserProcesses can be fixed, very good, but in other distributions I have not seen forcing KillUserProcesses to yes to achieve this. Also, I don't know how it will affect any other DEs that the user may have installed simultaneously, because GNOME, at least, does not have this problem, even without KillUserProcesses.
(In reply to Rex Dieter from comment #35) > I tested with and without KillUserProcesses=yes (changing this value in > logind.conf, and rebooting). About 5 attempts each: > * Without it, I do see lingering processes on logout, but was never able to > reproduce any failed logins. > * With it, I did not see any lingering processes on logout, and all re-login > attempts were successful (unsurprising). Till now, I have seen that the login fails randomly. In https://bugzilla.redhat.com/attachment.cgi?id=1630484, there is a line that says Linger: no. I don't know whether that is what you mean by lingering. Anyway, I tried once more:- In /usr/lib/systemd/system/sddm.service, in the [Service] section, replace the EnvironmentFile= line with just the line UnsetEnvironment= (just that much, nothing following the = sign). This too seems to work.
By the way, editing logind.conf has not helped other users either. See, e.g., comment #2 and comment #5 (although it is claimed that comment #5 refers to a different issue, I too have been unsuccessful with editing logind.conf to set KillUserProcesses=yes).
(In reply to Rex Dieter from comment #34) > We won't be incorporating any hacks like running 'loginctl kill...' anywhere > officially (so please don't suggest anyone do that). Besides, that's > precisely what > KillUserProcesses=yes > is supposed to do in a cleaner way. You advised using loginctl in https://bugzilla.redhat.com/show_bug.cgi?id=1742893#c3 (though not in a configuration file), which is why I thought it might be worth trying it.
Comment #37 also seems invalid. It still doesn't work with UnsetEnvironment=. I have also tested with erasing the ...Environment... line entirely, disabling SELinux, KillUserProcesses=yes, KillUserProcesses=yes + KillExcludeUsers=, KillUserProcesses=yes + KillExcludeUsers=sddm, UserStopDelaySec=0, UserStopDelaySec=infinity, loginctl [--signal=...] kill-user ..., loginctl [--signal=...] kill-session ..., loginctl terminate-user ..., loginctl terminate-session ..., loginctl flush-devices, loginctl terminate-seat ..., kdeinit5 [--no-fork|--no-kded|--suicide] +program, pulseaudio --kill + pulseaudio --start --daemonize=no, pulseaudio --cleanup-shm (if I haven't forgotten anything!). Nothing works.
Following the instructions under "How to Test" at https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation#How_To_Test, I disabled dbus-broker and enabled dbus-daemon and am not having this problem anymore. I did this because when I listed the processes left over after logout I saw dbus-broker and killing that usually let me login again. systemctl disable dbus-broker.service systemctl --global disable dbus-broker.service systemctl enable dbus-daemon.service systemctl --global enable dbus-daemon.service
(In reply to chillyleaf from comment #41) > Following the instructions under "How to Test" at > https://fedoraproject.org/wiki/Changes/ > DbusBrokerAsTheDefaultDbusImplementation#How_To_Test, I disabled dbus-broker > and enabled dbus-daemon and am not having this problem anymore. I did this > because when I listed the processes left over after logout I saw dbus-broker > and killing that usually let me login again. > > systemctl disable dbus-broker.service > systemctl --global disable dbus-broker.service > systemctl enable dbus-daemon.service > systemctl --global enable dbus-daemon.service I've tried it. It doesn't work
(In reply to chillyleaf from comment #41) > Following the instructions under "How to Test" at > https://fedoraproject.org/wiki/Changes/ > DbusBrokerAsTheDefaultDbusImplementation#How_To_Test, I disabled dbus-broker > and enabled dbus-daemon and am not having this problem anymore. I did this > because when I listed the processes left over after logout I saw dbus-broker > and killing that usually let me login again. > > systemctl disable dbus-broker.service > systemctl --global disable dbus-broker.service > systemctl enable dbus-daemon.service > systemctl --global enable dbus-daemon.service I tried it but I ran "systemctl disable dbus-broker.service" and "systemctl --global disable dbus-broker.service" first then tried to logout and was successful every time. but that produced a new error Plasma update error could not activate remote peer. after logging back in I ran "systemctl enable dbus-daemon.service" and "systemctl --global enable dbus-daemon.service" hoping it would clear the new plasma update error which it did not. not sure but I am happy I can now logout.
FYI, if you really want a proper test of switching dbus providers, you need to reboot (not just logout/login).
(In reply to Rex Dieter from comment #44) > FYI, if you really want a proper test of switching dbus providers, you need > to reboot (not just logout/login). It tried it in that way and it doesn't work. I'm thinking if snap could be related to this.
(In reply to Carlos from comment #45) > (In reply to Rex Dieter from comment #44) > > FYI, if you really want a proper test of switching dbus providers, you need > > to reboot (not just logout/login). > > It tried it in that way and it doesn't work. > > I'm thinking if snap could be related to this. I removed snap from my system and this made no differences
So I have updated 3 computers to fedora 31, a desktop pc (Dell 7010) and 2 laptops (HP DV5). only one laptop did not have this issue logging out. Any ways when I did the steps suggested by chillyleaf from comment #41 it worked fine on my desktop but I also ran "loginctl kill-user <username>" and I was able to log out and back in. I then did the same process for my laptop without running the loginctl..command and I was not having any success at logging out. I was brain storming what could be different, after going through systemd looking at settings I remembered that command which is listed at the start of this thread somewhere I then ran that command after the ones suggested by chillyleaf from comment #41 and then ran in the terminal "loginctl kill-user <username>" I am able to logout and in. Hope this helps I am not an expert but this has worked for me on 2 different computers.
There's been no updates on this bug for a month. Has it been silently fixed by an update? Also this bug does also occur on F31 so perhaps it should be updated to reflect that if it hasn't been fixed?
(In reply to Ananda Samaddar from comment #48) > There's been no updates on this bug for a month. Has it been silently fixed > by an update? Also this bug does also occur on F31 so perhaps it should be > updated to reflect that if it hasn't been fixed? I could reproduce the bug a couple other times. In this month I simply gave up of relogin the most of the times :P But I'll do some test on the further days to confirm if this bug is still reproducible (probably it is)
(In reply to Carlos from comment #49) > (In reply to Ananda Samaddar from comment #48) > > There's been no updates on this bug for a month. Has it been silently fixed > > by an update? Also this bug does also occur on F31 so perhaps it should be > > updated to reflect that if it hasn't been fixed? > > I could reproduce the bug a couple other times. In this month I simply gave > up of relogin the most of the times :P > > But I'll do some test on the further days to confirm if this bug is still > reproducible (probably it is) I confirm that the bug is still present.
Hi, I implemented an upgrade from F29 to F30 3 months ago, and this issue occurs for me too. I leave the laptop for at least 30 minutes as logged out, and cannot log back in. Implemented : /etc/systemd/logind.conf to include: KillUserProcesses=yes This has resolved the issue. System is updated every day. Regards, Shadders.
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.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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.