Second unity8 user session hangs with a black screen

[Pat McGowan]

Login to user1 using u8 as the session
login to a second session and select u8 as the session

The screen goes black and the fan comes on indicating something is in a tight loop
Waited for several minutes and it stays in that state. A hard power cycle is needed.

This is with the Zesty as of 3/15, no extra packages installed.

[Pat McGowan (pat-mcgowan)]

setting on u8c-1 if possible

[Michael Terry (mterry)]

I was able to log into two different users with unity8 simultaneously.

So that's positive. Maybe this isn't an everybody thing. It might be a graphics driver issue? Like Mir can't handle it in some cases? Adding Mir task to see if that's a crazy thought.

/me is running Dell XPS 13 (intel graphics)

[Pat McGowan (pat-mcgowan)]

I have a samsung also with Intel graphics.
When I get a console login I see a number of upstart jobs running, the top one at around 16% cpu. Unity8-dash and dbus-daemon are also running as the second user.
Unity8 is running as the first user only.
I see crashes for url-dispatcher and unity8-policykit-agent

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Confirmed.

The problem is unity8 crashes/exits for the second user, right after:

[2017-03-16:09:39:09.588] QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-testuser'
[2017-03-16:09:39:09.588] qtmir.screens: ScreensModel::ScreensModel
[2017-03-16:09:39:09.589] QSocketNotifier: Can only be used with threads started with QThread
[2017-03-16 09:39:09.592597] mirplatform: Found graphics driver: mir:mesa-kms (version 0.26.1)
[2017-03-16 09:39:09.592630] mirplatform: Found graphics driver: mir:mesa-x11 (version 0.26.1)
[2017-03-16 09:39:09.592766] mirplatform: Found graphics driver: mir:stub-graphics (version 0.26.1)
[2017-03-16 09:39:09.592775] mirplatform: Found graphics driver: throw-on-creation (version 0.26.1)
[2017-03-16 09:39:09.593183] mirserver: Starting
[2017-03-16 09:39:09.607913] mirserver: Using nested cursor
[2017-03-16:09:39:09.608] qtmir.mir: PromptSessionListener::PromptSessionListener - this= PromptSessionListener(0x7fe14c16bc50)
[2017-03-16:09:39:09.608] qtmir.mir: PromptSessionListener::~PromptSessionListener - this= PromptSessionListener(0x7fe14c16bc50)
[2017-03-16:09:39:09.610] bind: Permission denied

Also confirmed the high CPU usage that follows. That's unity8-dash for the second user continuously restarting (because there is no server for it to connect to) -> bug 1578469

[Daniel van Vugt (vanvugt)]

Maybe wait for bug 1644237 to be fixed. That might do the trick.

[Michael Terry (mterry)]

Aha! My testing was accidentally done on my xenial+overlay laptop (hard to tell environments apart sometimes). I can confirm on zesty.

[Michael Terry (mterry)]

Ah... If you use unity8-greeter, you don't see this bug. I think this is due to each session trying to create a USC for itself and they are conflicting. I believe we were trying to stop doing that, instead always using a global USC, but that must not have been prioritized yet.

[Michael Terry (mterry)]

Some research -- this is because XDG_RUNTIME_DIR is empty for the second user... Not sure why yet.

You can see the message "QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-testuser'" in the log above.

The default for the mir socket that unity8 creates is $XDG_RUNTIME_DIR/mir_socket, which resolves to "/mir_socket" which unity8 can't create, bailing.

That env being empty is not tied to a specific user. I have two users and whichever one is second has this problem.

[Michael Terry (mterry)]

OK, more research. This looks to be a mismatch between what logind expects lightdm to do and what we actually do.

Mir sessions started by lightdm all use the same VT number (they all live on the VT owned by unity-system-compositor.

But logind does not allow two user sessions to be on the same VT. (It does allow greeter and user sessions to share one, which is why we didn't notice this bug when using unity8-greeter logging into a unity8 session.) The relevant logind check is listed below [1].

One fix would be to allow type=mir sessions to share a VT. But I'd like input from Robert Ancell before moving on that. It's possible lightdm should be doing something else or that we don't actually want to break the assumption in systemd that each session has its own VT.

[1]
        /*
         * Old gdm and lightdm start the user-session on the same VT as
         * the greeter session. But they destroy the greeter session
         * after the user-session and want the user-session to take
         * over the VT. We need to support this for
         * backwards-compatibility, so make sure we allow new sessions
         * on a VT that a greeter is running on. Furthermore, to allow
         * re-logins, we have to allow a greeter to take over a used VT for
         * the exact same reasons.
         */
        if (c != SESSION_GREETER &&
            vtnr > 0 &&
            vtnr < m->seat0->position_count &&
            m->seat0->positions[vtnr] &&
            m->seat0->positions[vtnr]->class != SESSION_GREETER)
                return sd_bus_error_setf(error, BUS_ERROR_SESSION_BUSY, "Already occupied by a session");

[Michael Terry (mterry)]

Robert, can you comment on this? Got a recommendation?

[Robert Ancell (robert-ancell)]

I don't know of any other method other than to make logind allow this case as you've suggested. We cannot make Mir sessions runs on different VTs as that would make USC not work anymore.

There may be an issue running X11 sessions through USC as they wont have type=mir but will share the same VT..

[Michael Terry (mterry)]

I filed the linked upstream bug. Lennart is on vacation for a couple more weeks, so this won't see quick action. pitti pointed me at old bug 1192842 which is basically an old dupe.

All signs are pointing at this being an involved fix that will require upstream buy-in. So I'm inclined to set this aside for now and just accept the bug for zesty, rather than try to make big changes to logind late in the cycle; changes that we may not end up using in that form long term.

[Daniel van Vugt (vanvugt)]

We could theoretically make the one USC instance appear (differently) on multiple VTs. In tinkering with Mir's VT code I came to realize that VTs are truly a virtual concept. If you ignore the existence of VTs then you can still forcefully start up your system compositor on the screen. Cooperating with the notion of a current VT is just being a good citizen.

That said, if we're going to support an arbitrary number of users then giving each one a different VT does not scale. USC should have a switch-session key combo of its own (similar to the existing Ctrl-Alt-Fn).

[Michael Terry (mterry)]

> That said, if we're going to support an arbitrary number of users then giving each one a different VT does not scale. USC should have a switch-session key combo of its own (similar to the existing Ctrl-Alt-Fn).

Well, we could give each user session its own VT up to our system VT limit. Then we could just hide the rest behind our own switch-session key? Would cover most cases elegantly.

[Dan Streetman (ddstreet)]

please reopen if this is still an issue