Merge lp:~vanvugt/lightdm/fix-1192051 into lp:~mir-team/lightdm/unity
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Robert Ancell | ||||
Approved revision: | 1618 | ||||
Merged at revision: | 1619 | ||||
Proposed branch: | lp:~vanvugt/lightdm/fix-1192051 | ||||
Merge into: | lp:~mir-team/lightdm/unity | ||||
Diff against target: |
75 lines (+25/-5) 4 files modified
src/plymouth.c (+22/-2) src/plymouth.h (+1/-1) src/seat-unity.c (+1/-1) src/xserver-local.c (+1/-1) |
||||
To merge this branch: | bzr merge lp:~vanvugt/lightdm/fix-1192051 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Ancell | Approve | ||
PS Jenkins bot (community) | continuous-integration | Approve | |
Review via email: mp+170362@code.launchpad.net |
Commit message
seat-unity: Wait for Plymouth to complete the "deactivate" command. Otherwise
we risk fighting for the VT device and Plymouth's error handling is not robust
enough to handle that, making it spin at 100% CPU and never deactivating.
(LP: #1192051)
Description of the change
I'm sure some kind of robustness fix could be done in plymouth instead, but:
1. I don't yet understand the full flow of this bug from lightdm to plymouth. Other than plymouth is spinning on an fd of "/dev/tty7" with errno==EIO. And waiting for the plymouth deactivate to properly complete (hence drmDropMaster), avoids the bug.
2. Our PPAs don't contain plymouth so packaging the fix there would take significantly more effort.
PASSED: Continuous integration, rev:1618 jenkins. qa.ubuntu. com/job/ mir-team- lightdm- unity-ci/ 20/ jenkins. qa.ubuntu. com/job/ mir-team- lightdm- unity-saucy- amd64-ci/ 1
http://
Executed test runs:
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins: 8080/job/ mir-team- lightdm- unity-ci/ 20/rebuild
http://