It does the same thing with icewm desktop, and I assume others.

Making progress.
Apparently this is a known issue with lxdm.  From the ArchLinux wiki

"What might be slightly surprising with LXDM is that, by default, it does not clear the last user's desktop background or kill the user's processes when that user logs out. "

https://wiki.archlinux.org/index.php/LXDM#Expected_Logout_Behavior

Taking the advice in the Arch Linux wiki but updating it to use systemd-logind I came up with this script

/etc/lxdm/PostLogout
#!/bin/sh

# Close processes on logout Bug 8209
#Find current session number
session=$(loginctl -p Sessions show-user $USER | cut -f2 -d"=" | cut -f1 -d" ")

#Terminate session
loginctl terminate-session $session

This works OK and closes all the processes and restarts lxdm.  It still needs some refining because it terminates the first session it finds owned by the current user.  If there were remote logins it could terminate the wrong session. Unfortunately I could not work out how to identify the current session uniquely.

The above PostLogout seems a little wrong to me. It would just kill the first session of that user. E.g. if you login on tty2 first, leave that logged in then go back and login grapically, all it will do is terminate you text login.

systemd itself has a setting for this. From "man logind.conf(5)":

       KillUserProcesses=
           Takes a boolean argument. Configures whether the processes of a user should be killed when she or he completely logs out (i.e. after her/his last session
           ended). Defaults to no.

(In reply to comment #3)
> The above PostLogout seems a little wrong to me. It would just kill the first
> session of that user. E.g. if you login on tty2 first, leave that logged in
> then go back and login grapically, all it will do is terminate you text login.
> 

yes I agree. That is why I said it needed more work. After I posted that script I realised I could use the environment variable XDG_SEAT to work out the graphical session, but when I tried out a new script I found that loginctl terminate.seat would not work as user, only as root. PostLogout executes as the user so it did not work.  But the day before I *was* able to run loginctl terminate_* as  user. weird.

I saw the KillUserProcesses option in logind.conf, but did not understand how to make it apply to just lxdm. Is it possible to define it per service?

(In reply to comment #4)
> I saw the KillUserProcesses option in logind.conf, but did not understand how
> to make it apply to just lxdm. Is it possible to define it per service?

Yes, but it would require it's own PAM setup and configuration that would pass specific arguments into pam_systemd module. This is likely not an easily workable solution overall as it sort of defeats the purpose of stacking PAM configs

Hi everyone. This ia a user from Arch Linux, but I came across the same problem too. After attaching gdb to the running lxdm-binary, it showed that there was nothing being run in xconn_clean. So I removed the ifdef 0 statements around the xcb related code to see if that would kill all the current user's processes on log out.

I still haven't figured out a way to get the phantom login to disappear, but at least the user processes aren't dangling.

Upstream bug report I filed: https://sourceforge.net/tracker/?func=detail&aid=3598280&group_id=180858&atid=894871#

CC: (none) => shadowkyogre.public+mgbt

Created attachment 3286 [details]
Comments out the ifdef 0 statements around libxcb specific code

Commenting on this again after some further experimenting. I saw that it deleted the user session if the user session selected was invalid (like startlxde when one doesn't have lxde). While in the case of a session that has a valid command (like pekwm on the livecd I was building), it didn't remove the logout session.

In both cases, LXDM executed the PostLogout script, though I haven't been able to do a bug trace using GDB on some of the functions in src/lxdm.c to determine why it's only executing the code responsible for removing the session if the user session doesn't exist.

(^Also tested on Arch Linux, using the latest git revision along with mentioned patch in bug report)

Forgot to add this to what I was saying in the previous comment:
A current workaround that I can find is using the server-reset=1 option in the [server] section of /etc/lxdm/lxdm.conf in order to get rid of the excess sessions.

Hi,

from our Mageia user is reported that it is the same issue in MGA4 (32 and 64bit too) with lxdm as https://bugs.mageia.org/show_bug.cgi?id=8209#c0.

As following this procedure from https://wiki.archlinux.org/index.php/LXDM#Incorrect_logout_handling does not help.

However, by using:

# systemctl list-units
we can see that lxdm.service is in fault status. After # systemctl restart lxdm.service is the same as before.

Only this command works to terminate user's session and no issue in the next (2nd) user session:
# loginctl kill-session $XDG_SESSION_ID


or change lxdm to other dm and then is no problem for users.

Needs to be fixed.

Thank you...

Priority: Normal => High
CC: (none) => chipo
Version: 3 => 4
Target Milestone: --- => Mageia 3

Valid 5RC9 20th april - see also bug 15168

$ loginctl list-sessions
   SESSION        UID USER             SEAT            
        c1       1000 user             seat0           
        c2       1001 user2            seat0

Hi,

I have tried to solve the problem with lxde-common-0.99.0-8.mga5.  Can anyone confirm that the solution works not only for me?

Best regards,

Nico.

CC: (none) => nicolas.salguero

re-assigning to current maintainer

CC: (none) => marja11
Assignee: oliver.bgr => nicolas.salguero
Target Milestone: Mageia 3 => ---

For Mga4, the problem seems to be very difficult to fix but, for Mga5, the problem seems to be solved so I close the bug.

Status: NEW => RESOLVED
Resolution: (none) => FIXED