lightdm sessions started by dm-tool lock (or a session locker) never get closed

[b3nmore]

dm-tool lock starts a new lightdm greeter (for unlocking) and a new logind session. After unlocking the greeter disappears, but the logind session never closes. loginctl session status c24 reports something like:

c24 - lightdm (103)
           Since: Thu 2014-05-22 18:38:27 CEST; 30min ago
          Leader: 7872
            Seat: seat0; vc8
         Display: :1
         Service: lightdm-greeter; type x11; class greeter
           State: closing
          CGroup: systemd:/user/103.user/c24.session
                  └─7907 init --user --startup-event indicator-services-start

This results in an accumulation of stale lightdm sessions after using e.g. a session locker for a while.

I get this issue on a freshly installed and fully updated Xubuntu 14.04.

[b3nmore (b3nmore)]

According to Robert Ancell (https://answers.launchpad.net/lightdm/+question/250693) the lightdm upstart user-session should clean up after itself; therefor I'm linking this issue to upstart.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christian Uceda (christianuceda)]

This is incredibly annoying, if you leave your computer permanently on sessions mount up each time you lock your screen, eventually sessions pile up to the point where you notice your computer running very slowly.

This bug has been there since Xubuntu 14.04 was released.

Most people do not notice this issue because they switch their computers off or do not lock their screens.

[Christian Uceda (christianuceda)]

To get rid of the proliferation of sessions I run this on a script:

loginctl | awk '$3~/lightdm/ {print $1}' | xargs -I{} loginctl terminate-session {}
ps aux | awk '$0~/^[l]ightdm.*indicator-services-start/ {print $2}' | xargs -I{} kill -9 {}

[b3nmore (b3nmore)]

Another workaround, at least for those not requiring the a11y-indicator (accessibility menu for visual impaired): removing the a11y-indicator from the lightdm session, seems to prevent the start of the sound-indicator. Hence the sound-indicator does not block the termination of lightdm session, hence the lightdm session vanishes after login.

The indicators started by lightdm are configured in the corresponding 'lightdm-*-greeter.conf' file (for xubuntu its '/etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf') in the line 'show-indicators='. Deleting the built-in "~a11y" solved the issue for me.

For a proper solution, one would have to investigate, why the sound-indicator is blocking the clean termination of the lightdm session. Maybe its some sort of reincarnation of https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1290575.

[Sergio Gelato (sergio-gelato)]

I'm seeing the same problem (on multiple systems), and have been looking at the lightdm and unity-greeter log files in an attempt to understand what is going on. Some additional observations:

* I see three processes survive the termination of the greeter session: init (aka Upstart), indicator-sound-service and indicator-bluetooth-service. The following children of the init process do terminate: indicator-messages-service, indicator-power-service, indicator-datetime-service, indicator-session-service, indicator-application-service.

* If I send a SIGTERM to the surviving indicator-sound-service and/or indicator-bluetooth-service, the init process respawns a new one, and the event is logged in /var/log/lightdm/x-N-greeter.log(.old) . To fully get rid of the session I need to kill (-TERM is enough) the init process. If I do so, the children go away too.

* The aforementioned greeter log does *not* say "DEBUG: Cleaning up" as I would have expected from reading the source code (and as seems to be happening on initial login). It does not say "DEBUG: unity-greeter.vala:605: Got a SIGTERM" either. Instead, I see:
---begin log excerpt---
init: indicator-bluetooth main process (21833) killed by TERM signal
init: indicator-bluetooth main process ended, respawning
init: indicator-power main process (21834) killed by TERM signal
init: indicator-power main process ended, respawning

** (unity-settings-daemon:21845): WARNING **: Name taken or bus went away - shutting down
init: indicator-datetime main process (21836) killed by TERM signal
init: indicator-datetime main process ended, respawning
init: indicator-sound main process ended, respawning
init: indicator-session main process (21853) killed by TERM signal
init: indicator-session main process ended, respawning
init: indicator-application main process (21854) killed by TERM signal
init: indicator-application main process ended, respawning
init: indicator-messages main process ended, respawning
init: indicator-power main process ended, respawning
init: indicator-datetime main process ended, respawning
init: indicator-session main process ended, respawning
init: indicator-application main process ended, respawning
init: indicator-messages respawning too fast, stopped
init: indicator-session respawning too fast, stopped
init: indicator-power main process ended, respawning
init: indicator-datetime respawning too fast, stopped
init: indicator-application respawning too fast, stopped
init: indicator-power main process ended, respawning
init: indicator-power main process ended, respawning
init: indicator-power main process ended, respawning
init: indicator-power main process ended, respawning
init: indicator-power main process ended, respawning
init: indicator-power main process ended, respawning
init: indicator-power main process ended, respawning
init: indicator-power respawning too fast, stopped
[+1548,34s] WARNING: unity-greeter: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.

(unity-settings-daemon:21845): Gdk-WARNING **: unity-settings-daemon: Fatal IO error 2 (No such file or directory) on X server :1.
---end log excerpt---
(+1548,34s is 0.13 seconds after authentication completi...

[Matteo Panella (mpanella)]

It looks like that nobody is actually issuing the indicator-services-end upstart signal, so the stop events of *all* indicators for lightdm sessions never get fired. The other indicators just die because the session bus disappears under their feet, but indicator-sound-service keeps hanging around (even respawning pulseaudio in some cases!).

I don't really know who's at fault here - IMHO not upstart, which is doing the right thing (respawning dead indicators until they try to respawn too fast). Perhaps the greeter should clean after itself - after all, the indicator-services-start is fired by it.

[Sergio Gelato (sergio-gelato)]

unity-greeter has code to kill upstart, but for some reason this isn't being executed. My best guess is that unity-greeter often (if not always) dies before it exits the GTK main loop. Does it receive a second SIGTERM, or a SIGPIPE? (When lightdm says "Stopping display server, no sessions require it", I would think.) This should be testable.

Amending my earlier comment #7, I do see "Got a SIGTERM" some of the time, but I hardly ever see "Cleaning up" (when unlocking; new logins are another story). Indeed upstart is not to blame: it shuts itself off cleanly when signalled; the problem seems to be that unity-greeter doesn't send out that signal as it is supposed to.

[Christian Uceda (christianuceda)]

For those desperate because they work for companies who take locking screen as a serious thing, this is the workaround I came with, have been running for a few weeks and it does the job well so far.

The script if run via cron every 10 mins will keep your system clean of lightdm dead sessions, your system will not get sluggish over time, this is not an ideal solution but it is a good compromise until the issue is fixed for good.

[begin file: lightdm_clean.sh]
#!/bin/bash
# Cleans lightdm session leftovers in Ubuntu 14.04.x
# Christian Uceda 2015 v0.0.2
set -u

declare PID=""
declare -i SESSION_COUNTER=0
declare -i INDICATOR_COUNTER=0
declare STATUS=""
declare SESSION=""
declare CRONMODE=""

# Send output to the console if not running on cron mode
function echo_print(){
    if [ ! "${CRONMODE}" == "yes" ]
    then
        echo -e "${1:-}"
    fi
}

# -------------------------8<--------------------- Script body

# Root required
if [ $(id -u) -ne 0 ]
then
    echo -e "\nI can only run as root.\n"
    exit 1
fi

if [ "${1:-}" == "-cron" ]
then
    CRONMODE="yes"
fi

# Get rid of lightdm "closing" sessions
while read SESSION
do
    STATUS=$(loginctl session-status "${SESSION}" | awk '$1~/State/ {print $2}')
    if [ "${STATUS}" == "closing" ]
    then
        ((SESSION_COUNTER++))
        echo_print "Teminating session: ${SESSION}"
        loginctl kill-session "${SESSION}" &>/dev/null
    fi
done < <(loginctl | awk '$3~/lightdm/ {print $1}')
echo_print "\nTerminated: ${SESSION_COUNTER} sessions.\n"

# Notify if there are still some stray indicators (if not running in cron mode) can be removed if desired.
# I used it to verify the operation did not left any stray indicators.
if [ ! "${CRONMODE}" = "yes" ]
then
    while read PID
    do
        ((INDICATOR_COUNTER++))
        if [ ! "${PID}" == "" ]
        then
            echo_print "Found indicator pid: ${PID}"
        fi
    done < <(ps aux | awk '$0~/^[l]ightdm.*indicator-services-start/ {print $2}')
    echo_print "Found: ${INDICATOR_COUNTER} stray indicators.\n"
fi

exit 0
[end of file]

To test it lock and unlock the screen a couple of times and then run it manually, run it from root's cron like:

*/10 * * * * /usr/local/sbin/lightdm_clean.sh -cron

[Jonathan Sahagun (aj-sahagun)]

Hello, here's what I did on my Xubuntu installation that seems to work:

In this file:
/etc/xdg/xdg-xubuntu/lightdm/

In line 27, in a default installation, it reads:
show-indicators=power;~session;~language;~a11y;~power;

Remove the first "power" entry, leaving only the built-in indicators:
show-indicators=~session;~language;~a11y;~power;

Save the file, and any subsequent lock screens and the processes they spawn should now exit properly upon screen unlock.

I can't say for sure why it solves the issue on my Xubuntu, but I suspect that trying to include two power indicators might cause one or the other to prevent lightdm's indicator services instance from properly terminating.

Can you see if this solves the issue on your computers?

[Sergio Gelato (sergio-gelato)]

* Jonathan Sahagun [2016-01-29 12:51:08 +0000]:
> In this file:
> /etc/xdg/xdg-xubuntu/lightdm/

You probably mean /etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf .

> In line 27, in a default installation, it reads:
> show-indicators=power;~session;~language;~a11y;~power;
>
> Remove the first "power" entry, leaving only the built-in indicators:
> show-indicators=~session;~language;~a11y;~power;
>
> Save the file, and any subsequent lock screens and the processes they
> spawn should now exit properly upon screen unlock.

Not for me, they don't. (I rebooted after making the change you suggested
and before testing it.)

> Can you see if this solves the issue on your computers?

Here it doesn't. Of course there may be more than one issue. Could you look
at the end of your /var/log/lightdm/x-1-greeter.log{,.old} files? I'm still
seeing unity-greeter crash instead of exiting cleanly:

[+85,90s] WARNING: unity-greeter: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.

In my case the lingering processes are mostly indicator-sound and
indicator-bluetooth, with pulseaudio occasionally showing up too.
I'd happily turn these off too (especially the Bluetooth one for
which our workstations aren't supposed to have any hardware) but don't
see how.

[Jonathan Sahagun (aj-sahagun)]

Hi Sergio,

Yes I did mean /etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf , thanks for that.

Here's what I have for x-1-greeter.log:

--------
(lightdm-gtk-greeter:2212): Gtk-CRITICAL **: gtk_container_foreach: assertion 'GTK_IS_CONTAINER (container)' failed

(lightdm-gtk-greeter:2212): Gtk-CRITICAL **: gtk_container_foreach: assertion 'GTK_IS_CONTAINER (container)' failed

(lightdm-gtk-greeter:2212): Gtk-CRITICAL **: gtk_container_foreach: assertion 'GTK_IS_CONTAINER (container)' failed
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
--------

Unfortunately, I don't know what these entries mean. The .old file contains exactly the same messages, except for having a different PID listed.

Also, it might be worth mentioning that I'm on Xubuntu 14.04, and have these indicator related entries unchecked in my Session and Startup GUI, under Application Autostart:

Indicator Application
Indicator Power
Indicator Sound

I unchecked these as a previous troubleshooting step, and left them unchecked since they'll be started anyway by the indicator panel applet.

[Sergio Gelato (sergio-gelato)]

Silly me, I had overlooked the fact that we aren't using the same greeter. I've got [SeatDefaults]greeter-session=unity-greeter in /etc/lightdm/lightdm.conf. So of course your solution didn't work for me. (I need to give users a choice of desktop sessions, and found unity-greeter to be better at remembering a user's last session.)

You may have found a valid workaround for GTK greeter users; unfortunately I cannot switch to it.

[James Paige (bob-hamsterrepublic)]

> Can you see if this solves the issue on your computers?

I am pleased to report that this workaround fixes the problem for me. Thanks! (Xubuntu 14.04)

[Matteo Panella (mpanella)]

> Can you see if this solves the issue on your computers?

No luck here (Xubuntu 14.04), what actually did fix the issue was installing the latest stable release of lightdm-gtk-indicator from the upstream ppa. This caused a few hiccups with the Greybird theme, but at least the ghost sessions are gone without any kind of workaround.

This is a glaring red sign that neither lightdm nor upstart are the appropriate packages for this issue, but lightdm-gtk-greeter is.

Anyone proficient with bzr willing to perform a bisect between 2.0.1 (ppa - working) and 1.8.5 (trusty-updates, not working)?

[Sergio Gelato (sergio-gelato)]

> This is a glaring red sign that neither lightdm nor upstart are the
> appropriate packages for this issue, but lightdm-gtk-greeter is.

That still doesn't explain how I'm getting the problem with unity-greeter. There may be more than one bug at play here. Maybe my issue is better tracked by bug #1410584 (please don't merge it with this one until it's been established that they are in fact the same).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christian Uceda (christianuceda)]

Unbelievable

Since this bug was originally released:

14.04 has had 4 mayor updates, 14.04.1, 14.04.2, 14.04.3, 14.04.4, soon to be .5, 16.04 has been released (soon to be 16.04.1) and this bug is still there.

It is BASIC issues like these that give Linux distros a bad name/reputation, locking the screen is such a basic piece of functionality that it is mind boggling that for a start this is even an issue, without getting into the fact that years have gone by and officially nothing have been done about it other than 2 years later recognize it as a bug.

:-(

Let's hope this bug gets fixed solely by the inertia of upstream, because if we have to wait for Canonical we'll die of old age.

[Sean Davis (bluesabre)]

Last updated in 2016. Is this still an issue with these greeters?