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

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.

> 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).
Probably one X log for seat0 and one for seat-1 would be most
interesting, just to see which display devices it ends up using.
> 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.
Sorry you're right, I saw the 'username' lines but didn't follow
through to the authentication lines which do only seem to appear once.
> > This itself isn't a problem, as you can run `dm-tool
switch-to-greeter`
> 
> 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:
Interesting.  I think it would be worth trying the dm-tool command
anyway.  Not so much to start another session, but to see whether it
triggers your loop.  If it does trigger another loop, it means the
ultimate cause is something trying to start another login
session/greeter on the seat, and if it doesn't trigger the problem,
it's another possibility that can be crossed off the list.

My reasoning is that something could be trying to lock the display for
some reason after some time, which I think can be implemented in the
same way as starting another session on the seat (switching back to the
original session once the authentication is successful).  So confirming
or eliminating the multi-session-on-one-seat theory will be useful
either way.
> so the comment refers to this as "LP bug #1371250"; still not
sure
> what "LP" refers to but maybe you know?
I'm not a LightDM dev and haven't been around long enough to know what
they used before GitHub, but a DuckDuckGo search for "lightdm bug
1371250" came up with Launchpad:

  https://bugs.launchpad.net/lightdm/+bug/1371250
> > 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/...
Interesting, I could never get that to work and had to configure things
manually.  Yes that is the 'new' way if you are lucky enough to get it
to work.  If you can post a link to the instructions you used let me
know because I would rather do that than use finicky X config files.

Essentially as far as I understand it, it tags those resources with a
seat number and then the default X config files are set to pick up
those tags.

I guess thinking about it, if you did configure the X file manually, it
would probably just pick one device instead of trying them all, but
still complain that it's already in use?  Hard to say without trying it
with dm-tool to find out.
> 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.
LightDM wouldn't do this on its own, something else would be triggering
it.  If dm-tool switch-to-greeter actually works, then that will tell
us that it's not even trying to start another greeter but something
else is happening.
> 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.
Again dm-tool can confirm that theory :)

Cheers,
Adam.