[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