please stop greeter gracefully when stopping a display server
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| unity-greeter (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
Dear maintainer,
When lightdm is stopped or restarted, unity-greeter does not get a chance to run its cleanup code, but simply aborts due to the X server going away. Most of the greeter session components die the same way, but the session upstart does not. It keeps running and attempting to respawn services, which results in these few processes and the logind session staying around.
I'm not sure whether this bug belongs properly to lightdm or unity-greeter. It's possible the greeter should react more gracefully when the X server vanishes. I'm filing this against lightdm right now because I feel like all the necessary code for this already exists, it just needs to be called in the right order at the right time. Maybe it just needs to wait for the sessions attached to a particular display server to finish before stopping that server.
Thanks.
| Ryan Tandy (rtandy) wrote | #1 |
| summary: |
- please stop greeter gracefully when stopping lightdm + please stop greeter gracefully when stopping a display server |
| Robert Ancell (robert-ancell) wrote | #2 |
| affects: | lightdm (Ubuntu) → unity-greeter (Ubuntu) |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in unity-greeter (Ubuntu): | |
| status: | New → Confirmed |
A similar thing happens when you switch to a second user, and then switch back to the original user. In this case the greeter actually is sent SIGTERM, but the display server is stopped soon after, before the cleanup has finished.
lightdm.log says:
[+43.64s] DEBUG: Seat seat0: Returning to existing user session userone
[+43.64s] DEBUG: Unlocking login1 session c8
[+43.64s] DEBUG: Activating VT 7
[+43.64s] WARNING: Error using VT_WAITACTIVE 7 on /dev/console: Interrupted system call
[+43.64s] DEBUG: Seat seat0: Stopping greeter
[+43.64s] DEBUG: Session pid=4468: Sending SIGTERM
[+43.64s] DEBUG: Activating login1 session c8
[+43.64s] DEBUG: Session pid=4993: Exited with return value 0
[+43.64s] DEBUG: Seat seat0: Session stopped
[+43.66s] DEBUG: Session pid=4468: Exited with return value 0
[+43.66s] DEBUG: Seat seat0: Session stopped
[+43.66s] DEBUG: Seat seat0: Stopping display server, no sessions require it
[+43.66s] DEBUG: Sending signal 15 to process 4463
[+43.81s] DEBUG: Seat seat0 changes active session to c8
[+43.92s] DEBUG: Process 4463 exited with return value 0
[+43.92s] DEBUG: DisplayServer x-1: X server stopped
[+43.92s] DEBUG: Releasing VT 8
[+43.92s] DEBUG: DisplayServer x-1: Removing X server authority /var/run/
[+43.92s] DEBUG: Seat seat0: Display server stopped
and x-1-greeter.log says:
[+22.94s] DEBUG: unity-greeter.
[+22.94s] DEBUG: settings-
[+22.94s] DEBUG: settings-
[+22.94s] DEBUG: unity-greeter.
g_dbus_
upstart: indicator-sound main process ended, respawning
upstart: indicator-keyboard main process ended, respawning
upstart: indicator-power main process ended, respawning
[...]
Note the SIGTERM handler is hit, but "Cleaning up" after the end of the main loop is not.
After that second display server has been shut down, its session upstart and some indicator processes are still running.