LightDM - May 2020 - lightdm goes into tight loop trying to create greeter sessions and fills up logs

> 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.
> 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.
> 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 presume you have configured the seats manually in the X config files.
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.

Cheers,
Adam.

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.