usplash is not started on shutdown/reboot

I think some of the comments from people who think /etc/init.d/gdm should call usplash_down are actually about this bug (eg. bug 159262).

Also, the end result seems to be that something else starts usplash much later in the init sequence, which results in an empty usplash progress bar at the very end. I think this is the cause of reports like bug 216266.

I'm filing this separately because those reports are very confused and may refer to multiple issues. This one seems pretty clear.

thank matt, the version you mention looks a debian one and not an ubuntu one, the current intrepid package still have this patch here, that's weird

confirming the issue

I instrumented /sbin/usplash_down and straced gdm, and it's simply never invoked. Perhaps the code paths changed and the patch no longer has the intended effect?

I think what's happened is that the actual shutdown process is now invoked via consolekit rather than from gdm:

 5489 ? S 0:00 /usr/lib/policykit/polkitd
 5497 ? S 0:00 /bin/sh /usr/lib/ConsoleKit/scripts/ck-system-restart
 5498 ? R 0:00 \_ /bin/sh /sbin/shutdown -r now

This ought to be fixed somewhere below gdm, either in gnome-session or consolekit. gnome-session has:

static void
do_attempt_shutdown (GsmConsolekit *consolekit)
{
        if (gsm_consolekit_can_stop (consolekit)) {
                gdm_set_logout_action (GDM_LOGOUT_ACTION_NONE);
                gsm_consolekit_attempt_stop (consolekit);
        } else {
                gdm_set_logout_action (GDM_LOGOUT_ACTION_SHUTDOWN);
        }
}

Just to add a cat amongst the pigeons this fault is in Kubuntu as well! same issue but I use KDM.

Cary

When this bug is fixed, bug 277058 should be fixed at the same time.

I played around with this a little bit. Adding the usplash_down call to /etc/init.d/usplash "stop" fixes the bug to 80%, you still get some seconds of a black text screen with a cursor, until usplash kicks in (the time between killing gdm and calling K01usplash).

Calling usplash_down right before killing gdm doesn't help either, since gdm does too many VT switches, and it looks the same.

So in order to avoid patching the gdm, kdm, ldm, and other *wm init scripts, fixing K01usplash is a safe and nonintrusive bandaid for intrepid at least (should look roughly as good/bad as hardy, which wasn't seamless either).

I'd rename it to K02usplash for safety

On Thu, Oct 02, 2008 at 10:38:15AM -0000, Martin Pitt wrote:
> I played around with this a little bit. Adding the usplash_down call to
> /etc/init.d/usplash "stop" fixes the bug to 80%, you still get some
> seconds of a black text screen with a cursor, until usplash kicks in
> (the time between killing gdm and calling K01usplash).

At least there are no text messages in that time (unless Network Manager
prints some?), which would be a great improvement.

> Calling usplash_down right before killing gdm doesn't help either, since
> gdm does too many VT switches, and it looks the same.
>
> So in order to avoid patching the gdm, kdm, ldm, and other *wm init
> scripts, fixing K01usplash is a safe and nonintrusive bandaid for
> intrepid at least (should look roughly as good/bad as hardy, which
> wasn't seamless either).

Sounds good to me.

--
 - mdz

Not 100% sure if I'm posting to the right bug, but my issue is the following: like many others, I initially get text instead of the splash when shutting down/rebooting (I'm running Intrepid beta with all updates). The splash does eventually show up, with an empty progress bar, following some messages about NetworkManager.

I've found, though, that if I first log out and then shut down/reboot from the GDM login screen, the splash appears seamlessly without any text. This would seem to support the idea that it's about the order or timing of events, right?

Hope this is helpful/relevant,
Shane

On Mon, Oct 06, 2008 at 11:05:45AM -0000, shane19174 wrote:
> Not 100% sure if I'm posting to the right bug, but my issue is the
> following: like many others, I initially get text instead of the splash
> when shutting down/rebooting (I'm running Intrepid beta with all
> updates). The splash does eventually show up, with an empty progress
> bar, following some messages about NetworkManager.

Yes, you've found the correct bug.

> I've found, though, that if I first log out and then shut down/reboot
> from the GDM login screen, the splash appears seamlessly without any
> text. This would seem to support the idea that it's about the order or
> timing of events, right?

Yes, this is because quitting from a logged-in desktop no longer goes via
gdm, but directly to consolekit.

--
 - mdz

Matt,

Thanks for the quick reply. So what can one do about this? I don't quite understand the workaround posted by Martin above, and I'm wondering if this is something that will be fixed with an update or something that an end user like myself should try to fix on their own. (I realize that this is only a matter of cosmetics, but if I wanted to get friends or family to switch over from Windows, for example, such a little point could cause reluctance. And I personally just find it annoying/inelegant.)

Shane

> I'm wondering if this is something that will be fixed with an update

Yes, it will be. Working on it ASAP...

This bug was fixed in the package usplash - 0.5.24

---------------
usplash (0.5.24) intrepid; urgency=low

  * debian/usplash.init, stop(): Call usplash_down if usplash is not already
    running. In previous releases, the display manager started it, but in the
    modern ConsoleKit world, nothing else triggers it any more. (LP: #264696)
  * debian/rules: Move stop rc.d priority to 02, to avoid racing with gdm
    (which is also at 01) when using init script parallelization.
  * Add debian/usplash.preinst to do above rc.d priority migration on updates.
    (Needs to be kept until after the next LTS)

 -- Martin Pitt <email address hidden> Wed, 08 Oct 2008 12:02:24 +0200