plymouth events

[Colin Watson]

Hi Scott,

I have the occasional bug report observing that plymouth doesn't start
when shutting down a live CD session booted with the "Install Ubuntu"
option.  I haven't actually been able to reproduce this myself, so I
assume that it's racy.  However, I've been trying to decipher the
plymouth job graph, bearing in mind
https://bugs.launchpad.net/upstart/+bug/447654 ("init: using 'and'
operators can cause hangs"), and was wondering if you could sanity-check
my conclusions.

Here are the relevant jobs:

plymouth-stop:

  start on (starting gdm
            or starting kdm
            or starting xdm
            or starting lxdm
            or starting ubiquity
            or starting oem-config
            or stopped rc RUNLEVEL=[2345]
            or starting rcS
            or starting mountall-shell)
  stop on stopped plymouth

plymouth:

  start on (starting mountall
            or (runlevel [016]
                and (stopped gdm
                     or stopped kdm
                     or stopped xdm
                     or stopped lxdm)))

ubiquity:

  start on (starting gdm
            or starting kdm
            or starting xdm
            or starting uxlaunch)
  stop on runlevel [06]

gdm:

  start on (filesystem
            and started dbus
            and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
                 or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                 or stopped udevtrigger))
  stop on runlevel [016]


Proving any of this is a right pain because of course all the debugging
information vanishes at reboot, but what I think happens is:

  runlevel 6 emitted
   -> starting plymouth (blocked)
   -> stopping gdm
   -> stopping ubiquity

  'stopping gdm' and 'stopping ubiquity' race because there's no
  relationship between them.  If 'stopping ubiquity' wins, then:

  stopped ubiquity
   -> (completes, shutting down X)
  stopped gdm
   -> starting plymouth

  If 'stopping gdm' wins, however:

  stopped gdm
   -> starting plymouth

  ubiquity is still stopping, so X may still be running, which means
  that plymouth is going to race with X, and will probably dismiss the
  splash screen as soon as X stops and switches back to tty1, or
  something along those lines, leaving the user with a plain text
  console on tty1.  Badness.


My proposal for fixing this is to change ubiquity's stop event to:

  stop on (stopping gdm
           or stopping kdm
           or stopping xdm
           or stopping uxlaunch)

This doesn't particularly change the conditions under which ubiquity is
stopped, except for adding runlevel 1, which is OK; but it means that
gdm etc. can't finish stopping until ubiquity has stopped, which means
that plymouth will definitely not start until both ubiquity and gdm have
stopped, which is what we want.

Does this look right to you?

Thanks,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]