During shutdown, systemd runs "plymouth --show-splash" and waits for the plymouth client to exit before shutting down the system. However, the plymouth program appears to exit before the plymouth daemon has finished processing the command. Thanks to systemd ultra-fast shutdown, this means that the system often shuts down with the plymouth splash only half-drawn. Quite an ugly experience for the user. I have also seen this issue in another case: I send a command to my theme so that it draws something specific on the screen # plymouth update --status="foo" I do this from a script, and at this point I require that the theme has finished the drawing operation triggered by the above command. Usually when this script is run, the plymouth client exits before the draw is complete. Would it be possible to modify the plymouth client behaviour to wait for the server to finish the requested operation before returning? (Perhaps enabled by an optional argument?) One way I think this can maybe be achieved: send a ping to the plymouth server (i.e. plymouth --ping) after sending the command in question, and don't quit until the ping returns. Assuming plymouthd executes commands serially, the ping will only execute and return after the earlier command has finished.
Plymouth already blocks the client for some cases, though not show-splash and not update. Ping wouldn't be sufficient, we don't guarantee things happen in order. What if you add "plymouth deactivate" after plymouth --show-splash ? That should work I think. As for update. we could potentially add protocol to block until replies are finished, though updates are also used for timing the boot progress, so we'd have to be careful not to break that timing. Not systemd itself does the equivalent of plymouth update, and it closes it's fd immediately, without waiting for the reply, so even if we deferred the reply it wouldn't help for systemd messages.
plymouth --show-splash is called from the systemd unit file. Are you suggesting that I modify the systemd unit file to add the deactivate command too? I think its fine that "update" doesn't block on completion by default, but having it as an optional block would be useful for my corner case.
yes, that's what I was proposing. We can make show-splash allocate a trigger, pass the trigger into the splash plugin and have the splash plugin fire the trigger when its completed showing up, that's probably worth while to do, but I wanted you to check if deactivate was sufficient to work around the problem. having a command a block until completion is something that needs to be implemented on a command by command basis, since the command may be doing things asynchronously. If you do plymouth some-command; plymouth --ping, it's possible the --ping will complete before some-command does. (think plymouth ask-for-password, which doesn't complete until the user enters their password)
note the systemd unit files are in plymouth now
Sorry for the delay in getting back to you here. In Fedora 18 (systemd X, plymouth X) this seems better. Have you modified anything here? According to systemd debug logs, systemd now starts plymouth-poweroff.service much earlier during shutdown (as the first .service that it handles - whereas in F17 it did a whole load of other stuff first). I haven't yet managed to see a shutdown with only half the screen rendered as before. (A point for interest: removing plymouth-poweroff.service reduces poweroff time from 8.7s to 3.8s on XO-1.5.) Also, we added a .service file to make the shutdown process take longer - since for us the shutdown splash acts as an information screen, we want it to be on screen for a bit longer. So maybe we can regard the shutdown case as solved/irrelevant. As for the other case mentioned: waiting for a draw triggered by --update to complete: I added "plymouth deactivate" to that point in the script and it seems to work. Does this command have the desired behaviour of waiting for all pending commands/drawing to complete without removing the splash from the screen? (It seems to, just want to check that its not coindidence)
Forgot to add in the versions we're dealing with (where I put X's): plymouth-0.8.7, systemd-188
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/plymouth/plymouth/issues/28.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.