canonical / mir

The Mir compositor
GNU General Public License v2.0
627 stars 100 forks source link

Mir stuck on shutdown when switched to a different TTY #2662

Open Saviq opened 2 years ago

Saviq commented 2 years ago

Steps

  1. install ubuntu-frame
  2. snap set ubuntu-frame daemon=true
  3. Ctrl+Alt+F* to a different TTY
  4. snap stop ubuntu-frame
  5. Ctrl+Alt+F4 to move back to tty4

Expected

  1. Frame shuts down cleanly

Current

  1. systemd ends up killing it after a timeout

Logs say:

wrz 23 10:15:31 michal-laptop ubuntu-frame.daemon[318871]: [2022-09-23 10:15:31.954889] < - debug - > mirserver: Handling User defined signal 1 from pid=0
wrz 23 10:15:41 michal-laptop ubuntu-frame.daemon[318871]: [2022-09-23 10:15:41.102850] < - debug - > mirserver: Handling Terminated from pid=1
wrz 23 10:15:41 michal-laptop systemd[1]: Stopping Service for snap application ubuntu-frame.daemon...
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: State 'stop-sigterm' timed out. Killing.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Killing process 318871 (frame) with signal SIGKILL.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Killing process 318912 (frame:gdrv0) with signal SIGKILL.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Killing process 318916 (frame) with signal SIGKILL.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Killing process 318917 (frame:gdrv0) with signal SIGKILL.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Killing process 318925 (n/a) with signal SIGKILL.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Killing process 318932 (frame) with signal SIGKILL.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Killing process 318960 (Mir/Workqueue) with signal SIGKILL.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Main process exited, code=killed, status=9/KILL
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Failed with result 'timeout'.
wrz 23 10:16:11 michal-laptop systemd[1]: Stopped Service for snap application ubuntu-frame.daemon.
wrz 23 10:16:11 michal-laptop systemd[1]: snap.ubuntu-frame.daemon.service: Consumed 17.028s CPU time.

Things are fine if you stay on tty4 and shut it down from remote. Sounds like #2658 maybe?

AlanGriffiths commented 2 years ago

Sounds like #2658 maybe?

Possibly, but #2136 could also be hanging a thread (or #2674). Would be good to attach gdb and poke around...

AlanGriffiths commented 2 years ago

Sounds like #2658 maybe?

Definitely not:

wrz 23 10:15:31 michal-laptop ubuntu-frame.daemon[318871]: [2022-09-23 10:15:31.954889] < - debug - > mirserver: Handling User defined signal 1 from pid=0
wrz 23 10:15:41 michal-laptop ubuntu-frame.daemon[318871]: [2022-09-23 10:15:41.102850] < - debug - > mirserver: Handling Terminated from pid=1

We're getting: SIGUSR1 - The VT switch; and, SIGTERM - not a "Fatal signal" (it should schedule a call to DisplayServer::stop() on the main loop

What is likely happening is that the VT switch has paused some thread that is assumed to be running by the shutdown code.