← Back to team overview

ubuntu-multiseat team mailing list archive

Re: Xubuntu 14.10 second seat screen lock not working / gets stuck


On 12/31/2014 04:54 PM, Schlomo Schapiro wrote:
> I contacted you via the "Contact the team admins" link
> on https://launchpad.net/~ubuntu-multiseat,

Apologies -- I didn't get that email.  I'll have to check to see if it
was somehow rejected or marked as spam.

> I first wanted to open a bug
> but could not quickly find the way how to "just" open a new bug on
> launchpad without using the ubuntu-bug program.

You can go to a package's list of bugs and click the "report a bug" link
in the upper right.  It'll take you to a URL like this:


>>> I have the impression that Xubuntu 14.10 does not support screen locking
>>> on seats other than seat0.
>>> What I observe is that if the screen locks it goes to the "This session
>>> is locked. You'll be redirected ..." message but stays there forever. I
>>> suspect that the main reason is the fact that lightdm cannot start
>>> another X server on this seat (VT switching beeing supported only on
>>> seat0).
>>> I tried telling lightdm via a seat-specific configuration that it cannot
>>> to user switching. As a result locking does not work at all (also bad)
>>> and the seat stays dead after the users logs out.
>> The screen locker/saver should only attempt VT switching if you click on
>> the "switch users" button (VT switching isn't involved when just trying
>> to unlock the screen).  So my guess is that VT switching isn't related
>> to the problem you're having.
> ​I don't understand. According to
> http://xubuntu.org/news/screen-locking-in-xubuntu-14-04/ light-locker
> heavily depends on lightdm beeing able to spawn another X server on the
> card and use VT switching to show that to the user. AFAIKT this does not
> work on secondare seats hence light-locker won't work there.

Oh, you're right -- my mistake.  Yup, looks like this is related to
session switching.  Because you're running utopic this *should* just
work.  I'll have to set up a multiseat utopic system and see if I can
reproduce the problem.

Support for session switching on non-seat0 seats was added in systemd
208 [1] and xorg-server 1.16 [2], both of which are available in utopic
(but not trusty).


>> My guess is that the problem stems from the lack of logind support. 
>> See:
>>     https://bugs.kde.org/show_bug.cgi?id=314989
>> According to that bug, logind integration is in plasma-workspace 5.x and
>> won't be backported to kde-workspace 4.x.
> ​How does this relate to the use case of XFCE, lightdm and multiseat?

It doesn't; I misread Xubuntu as Kubuntu.  I guess I'm not very with-it
today.  :(

> I actually could unlock the session with loginctl unlock-session (as
> root).
> It seems to me rather that light-locker just locks the session with the
> "This session is locked" but then lightdm cannot show the greeter
> anywhere to ask for a passwort to unlock it.

Yes; seems like something is trying to switch sessions but failing
somehow.  Anything interesting in lightdm or X logs?

> I read somewhere that there is an open issue that lightdm assumes the
> secondary seat to support User Switching (which it actually does not).
> dm-tool also shows this:
> $ dm-tool list-seats
> Seat0
>   CanSwitch=true
>   HasGuestAccount=true
>   Session1
>     UserName='user1'
> Seat1
>   CanSwitch=true
>   HasGuestAccount=true
>   Session4
>     UserName='user2'

It used to be true that non-seat0 seats couldn't support session
switching, but with the newer versions of X and logind in utopic,
session switching on non-seat0 seats should work.  So 'dm-tool
list-seats' might not be lying to you.

FYI, session switching traditionally worked via legacy VT switching,
which is why it only worked on seat0.  As of v208, logind exposes a dbus
API (TakeDevice()) to let logind open devices on behalf of programs like
X so that logind can gracefully manage handing off device access when
switching sessions.  Xorg server v1.16 started using this new API
instead of opening devices directly (which has the side benefit of
allowing X to run as non-root).

Some good reading material (but slightly outdated):

> That is why I tried adding this to lightdm.conf:
> [Seat:seat-1]
> allow-user-switching=false
> The effect was that Seat1 would not show as CanSwitch=true in dm-tool
> list-seats. And that light-locker would not lock the session any more
> (no more stuck on "This session is locked").  Which is good since the
> user cannot lock himself out any more. But the downside is that then it
> is impossible to lock the screen in Xubuntu

OK, so it seems like light-locker is correctly detecting whether the
seat is capable of session switching and if not does a fallback behavior
(which is apparently "do nothing").

> and that after logging out
> of the session there is no new login screen. Apparently lightdm does not
> start a new session on this seat after the first session is done.

That seems odd to me, and sounds like a lightdm bug...  Do the lightdm
logs show anything interesting?

> The reason I am contacting you as the mutliseat team is that I wanted to
> find out if anybody is aware of this issue (locking secondary seats with
> lightdm and light-locker) and working on it, at least conceptually.

I wasn't aware of it, but I have not been active on ubuntu-multiseat for
a while now (real life taking too much of my time).

> It seems to me that the current locking concept (using lightdm to show a
> *new* greeter to unlock) does not cover this use case at all :-(

But it should, given that utopic should support session switching on
non-seat0 seats.  I would expect trusty to have problems, but not utopic.

> If you say that I am the first one to observe this conflict then I'll be
> happy to open a bug report about it as you suggest (against which
> packages?).

Good question.  Probably light-locker since that is the only package
exhibiting symptoms.  If the underlying cause turns out to be elsewhere
then the bug can be moved.

> My workaround is now to use xscreensaver instead of light-locker. Works
> but ugly and much less integrated.

Good to know that there is a workaround.

> Testing daily images won't work since this is already a production
> system with a high WAF requirement and I don't have another system for
> testing (yet). Do you know about a good way to test this in a virtual
> machine instead of real hardware?

I believe linux-kvm supports multiple graphics and input devices, though
I have never tried it.


> Kind Regards,
> Schlomo

Follow ups