[LightDM] lightdm goes into tight loop trying to create greeter sessions and fills up logs

Greg Klanderman gak at klanderman.net
Fri May 1 16:25:15 UTC 2020


Hi Adam,

>>>>> On April 29, 2020 Adam Nielsen <a.nielsen at shikadi.net> wrote:

>> Did you look at the logs I posted on
>> the debian bug report?  After being started, lightdm runs fine on both
>> seat0 (VT7) and seat-1.

> I can't see any X logs for the successful sessions, only one X log
> where it complains that there's no display device and terminates, which
> causes LightDM to try to restart X, which leads to the loop you
> mentioned.

Sorry, I thought the lightdm log was most interesting and only kept
the X log for the one that failed.  I no longer have the corresponding
X logs, but I can send current ones if you think it will be helpful.
Let me know what you want; I have the X log from my xinit session on
seat0 VT1 (since March 4) and the lightdm X logs for seat0 VT7
(greeter only, since April 28) and seat-1 (logged in, since April 28).

I've changed a couple lightdm options since I first wrote, namely:

[LightDM]
#start-default-seat=false
minimum-display-number=5
logind-check-graphical=true

[Seat:*]
xserver-share=true
greeter-hide-users=false
greeter-allow-guest=false
greeter-show-manual-login=false
greeter-show-remote-login=false
user-session=cinnamon
allow-user-switching=false
allow-guest=false
autologin-guest=false
autologin-user=

previously only had the greeter-* ones.

>> The greeter remains running on seat0 (I am
>> logged in directly from the VT1 console terminal, where I started X
>> the old fashioned way) and my son has an active session on seat-1
>> where he logged in via lightdm/greeter.

> I think I can see this in the logs, and it looks like seat-1 logs out
> and back in once, successfully.

Hmm, I don't think seat-1 logs out and back in; the log shows starting
up until +8.87s, then from +1699.91s to +1706.86s (28m) my son logs in
on seat-1, then the next line is at +308685.52s (85.7h), when it
begins looping, failing to start a greeter on seat-1.

>> About 2-3 *days* later, it
>> decided that it needed to start a greeter on seat-1, and went into a
>> tight loop failing repeatedly.  I included the complete lightdm log up
>> until it starts looping.  Have been through several cycles of this,
>> and it seems to reliably happen a few days after restarting lightdm.

> It looks like something is triggering LightDM to run again on seat-1.
> This itself isn't a problem, as you can run `dm-tool switch-to-greeter`
> to start multiple sessions on the same seat (they each start on a
> different VT and you can switch between them like any other VTs).

> I am wondering whether something is causing this to happen in your
> case?  What happens if you use dmtool like this to start another
> session, do you get another one running on that seat, or does it
> trigger a similar loop?

I don't think you can run another session on seat-1; AFAICT only seat0
ever supports multiple sessions on linux, and the log seems to reflect that:

| [+0.48s] DEBUG: Seat seat-1 has property CanMultiSession=no

Hmm but I note that the code which would turn off user switching for
that seat after logging that line, in src/lightdm.c:add_login1_seat(),
at least in trunk, is commented out:

|   if (!login1_seat_get_can_multi_session (login1_seat))
|   {
|       g_debug ("Seat %s has property CanMultiSession=no", seat_name);
|       /* XXX: uncomment this line after bug #1371250 is closed.
|       seat_set_property (seat, "allow-user-switching", "false"); */
|   }

Where do I look up that bug?  github bugs only go to #119...

Here's the commit:

https://github.com/canonical/lightdm/commit/eefee6f361da235cadc36da532852905de8d209a

so the comment refers to this as "LP bug #1371250"; still not sure
what "LP" refers to but maybe you know?

This was a follow-up to

https://github.com/canonical/lightdm/commit/610d6abcf2e745714d962e861faedb572d1e32fb

adding "automatic multiseat support".

> I presume you have configured the seats manually in the X config files.

I have not configured the seats, nor do I have an Xorg.conf per-se.  I
thought those were obsolete (generated automatically) these days?
Anyway, I followed multi-seat instructions I found online which
essentially just boiled down to

# for each device corresponding to seat-1 (graphics card & USB hub)
loginctl attach seat-1 /sys/devices/...

> I am wondering why it is trying a whole bunch of display drivers (ati,
> amdgpu, modesetting, vesa, etc, etc.) before complaining that it can't
> find a valid display.  This normally only happens if you haven't
> specified a device in xorg.conf.  It's telling you to specify the BusID
> in xorg.conf but if you've manually configured the seats I would've
> expected you to already have done this.

I'm not sure why lightdm would try to start a greeter on seat-1 when
there is a session logged in, and seat-1 has property
CanMultiSession=no.

I restarted lightdm Tuesday morning, we'll see if this problem recurrs
in the next day or so.  Maybe one of the config changes I made will
solve the issue?  I did add allow-user-switching=false, which I
believe should also inhibit starting another greeter when there is an
active login session.

Guessing that may solve it given additional info I just dug up above
re: "LP bug #1371250".

many thanks,
Greg

> Cheers,
> Adam.


More information about the LightDM mailing list