Comment 3 for bug 1702892

There is a slight difference between unity-settings-daemon and gnome-settings-daemon code paths.

Specifically:

                msd = '/usr/bin/mate-settings-daemon'
                usd = '/usr/lib/unity-settings-daemon/unity-settings-daemon'
                gsd = '/usr/lib/gnome-settings-daemon/gnome-settings-daemon'

                if osextras.find_on_path(msd):
                    extras.append(subprocess.Popen(
                        [msd], stdin=null, stdout=logfile, stderr=logfile,
                        preexec_fn=self.drop_privileges))

                elif (osextras.find_on_path(usd)):
                    # Wait until xsettings plugin is activated
                    xsettings = SignalWatcher(self, usd,
                                              "org.gnome.SettingsDaemon",
                                              "/org/gnome/SettingsDaemon",
                                              "PluginActivated",
                                              "xsettings")
                    # the SignalWatcher will run until the signal is seen...
                    extras.extend(xsettings.run())
                    # At this point we're sure the usd xsettings plugin is
                    # available, we can continue setting up the session.

                elif osextras.find_on_path(gsd):
                    extras.append(subprocess.Popen(
                        [gsd], stdin=null, stdout=logfile, stderr=logfile,
                        preexec_fn=self.drop_privileges))

Thus in u-s-d case there is an extra blocking wait on u-s-d to initialise xsettings before proceeding.

I do not know if something similar is required in g-s-d case, to e.g. wait for g-s-d to be fully up.

However, longer term, imho ubiquity-dm should not at all be in use at all, and instead we should boot to gdm3 normally and have e.g. a casper override to start up in ubiquity installer mode, rather than full session.