| Summary: | plymouth client does not wait for server to process command | ||
|---|---|---|---|
| Product: | plymouth | Reporter: | Daniel Drake <dan> |
| Component: | general | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | rstrode |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Daniel Drake
2012-05-31 08:12:07 UTC
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.