Bug 1746586

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.