Merge lp:~mterry/lightdm/respawn into lp:lightdm

[Michael Terry]

Respawn lightdm if it dies unexpectedly.

Respawn lightdm if it dies unexpectedly.

Bug 1314659 notes that in Ubuntu Touch, the behavior if USC crashes is not great -- user is just left with a blank screen.

Right now, if USC crashes, lightdm also stops because its only display server died. But it doesn't come back up because 'respawn' isn't specified in its upstart file. I'd argue that it's correct to do so and is an easy way to fix the bug from an end-user perspective.

In Desktop land, if the user X dies, I believe we just shunt the user to the greeter, which isn't bad. But if the greeter is the only session up and its X dies, I think we'd be stuck in the same situation as Touch is now and would thus benefit from this change.

The one oddity is that Mir doesn't handle stale sockets well. This is a known issue, and most other mirservers (unity8 and unity8-greeter) just delete the socket before using it -- unity8 in its upstart job, the greeter in a wrapper script.

So I've added a line to remove the socket before use.

[Robert Ancell (robert-ancell)]

This is going to break fallback mode on desktop right?

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:1978
http://s-jenkins.ubuntu-ci:8080/job/lightdm-ci/285/
Executed test runs:
    FAILURE: http://s-jenkins.ubuntu-ci:8080/job/lightdm-trusty-amd64-ci/79/console
    FAILURE: http://s-jenkins.ubuntu-ci:8080/job/lightdm-trusty-armhf-ci/79/console

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/lightdm-ci/285/rebuild

review: Needs Fixing (continuous-integration)

[Michael Terry (mterry)]

I don't think so. LightDM only exits if no display managers can be brought up. If USC can't start, it tries the next one (usually X).

If LightDM itself has exited, such that upstart has the decision to respawn or not, things are bad for the user.

[Robert Ancell (robert-ancell)]

From failsafe-x.conf:

start on stopped lightdm EXIT_STATUS=[!0] or stopped gdm EXIT_STATUS=[!0]

Will this still launch or will the respawn ensure the "stopped lightdm" event never occurs?

[Robert Ancell (robert-ancell)]

Obviously you're not using failsafe-x on touch, just wondering if this is a change in behaviour and if we care about lightdm getting stuck in restart loops.

[Michael Terry (mterry)]

Oh sorry! I was thinking of the internal-to-lightdm fallback mode (like mir to x etc).

For failsafe... I'm 90% sure that "stopped lightdm" is not emitted during a respawn. I'd have to look at docs again. As for restart loops, there is a default respawn limit, but we can override with a "respawn limit" stanza.

[Robert Ancell (robert-ancell)]

OK, so I think we need to have a wider discussion (ubuntu-desktop mailing list?) as to is failsafe-x relevant anymore and do we switch to respawning instead.

[Robert Ancell (robert-ancell)]

As for the socket removal - I'm a little wary about just deleting it on startup (we don't know if it's owned by an existing lightdm process. If it needs to be more unique we should pick a more unique name). Can't that just be fixed in u-s-c if it's the only Mir compositor that doesn't do "the right thing"?

[lp:~mterry/lightdm/respawn]

1979. By Michael Terry on 2014-05-01

Forget about cleaning up socket; Mir does that for us now

[Michael Terry (mterry)]

Ah! The just-landed Mir 0.1.9 fixes socket cleanup itself. So that's no longer a concern and I've dropped it from this merge.

I will test more with failsafe-x.

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:1979
http://jenkins.qa.ubuntu.com/job/lightdm-ci/286/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/lightdm-trusty-amd64-ci/80/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/lightdm-trusty-armhf-ci/80/console

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/lightdm-ci/286/rebuild

review: Needs Fixing (continuous-integration)

[lp:~mterry/lightdm/respawn]

1980. By Michael Terry on 2014-05-01

Set a relatively conservative respawn limit

[Michael Terry (mterry)]

OK, after some investigation:

As is, this will break failsafe-x. But only because failsafe-x is using an imprecise start-on condition. It should be "start on stopped lightdm RESULT=failed" instead of "start on stopped lightdm EXIT_STATUS=[!0]" because when a job is stopped due to respawning too frequently, EXIT_STATUS isn't even set. Plus, jobs can technically change which exit statuses are normal to include non-zero ones. But anyway. I'll try to get that job definition sorted out with Maarten.

But with a fixed failsafe-x, this branch works fine. I've used a conservative "fail if we respawn more than twice in 15 seconds" condition. And if we hit that, a fixed failsafe-x will start.

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:1980
http://jenkins.qa.ubuntu.com/job/lightdm-ci/287/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/lightdm-trusty-amd64-ci/81/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/lightdm-trusty-armhf-ci/81/console

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/lightdm-ci/287/rebuild

review: Needs Fixing (continuous-integration)

[Robert Ancell (robert-ancell)]

OK, sounds great. Since Jenkins has completely confused itself feel free to merge to this into lp:lightdm whenever the associated changed for failsafe-x land.

review: Approve

=== modified file 'debian/lightdm.upstart'
--- debian/lightdm.upstart	2014-02-04 09:40:00 +0000
+++ debian/lightdm.upstart	2014-05-01 18:20:22 +0000
@@ -16,6 +16,9 @@
 
 stop on runlevel [016]
 
+respawn
+respawn limit 2 15
+
 emits login-session-start
 emits desktop-session-start
 emits desktop-shutdown