Hi,
I’m working on optimizing the boot appearance on a Toradex Verdin iMX8M Plus WB.
I need to delay the splash screen disappearing to ‘cover’ the docker service start time.
What I want to achieve is: let the splash screen disappears once all my containers all started and running. Ideally, I would like to have a command to send to the host machine (via dbus or something similar) via container to say ‘hey system, remove the splash screen’. This will be the most preferable, robust and flexible way.
I can accept to set a ‘fixed delay time’ and than tweak the value to suite my use-case.
I try to follow this discussion to create a plymouth-wait-for-animation.service. However, this simply delays all the subsequent services (see chain-with-service.svg) and delays the docker start too.
Attached two boot chains, with and without plymouth-wait-for-animation.service chains.zip (24.2 KB)
I’ve never tried such a task before so I’m only speculating here on ideas/theories. The Plymouth splash screen should only terminate via the following systemd service:
As you can see there are multiple things it waits for as seen in After=, which controls which units should start before this. One of these units is docker.service. However, this is just the Docker daemon service. The service that actually starts your container is probably docker-compose.service. Maybe tweaking plymouth-quit.service here would allow you better control over when the splash screen exits.
Again just an idea nothing that has been tested or verified yet.
said that to obtain an acceptable solution for my case I’ve worked by tries because I have poor knowledge about the subject,
Jeremias is right: you have to play with the After dependencies of plymouth-quit.service.
In my case I added ‘wayland-app-launch.service’ in the After dependencies of plymouth-quit.service to obtain the splash screen onscreen until the wayland/weston block launch my dedicated Qt app and then removed ‘plymouth-quit-wait.service’ from the After dependencies of weston.service to obtain the blanking of the splashscreen before my Qt app launches.
That is enough for me.
In your case, better, I think that if you create a service that start after the last part of the docker launch block and set a After dependency into plymouth-quit.service related to that just created service, the splahscreen remains onscreen exactly until your containers are up and running.
however after the reload command the system shows: Failed to reload plymouth-quit.service: Job type reload is not applicable for unit plymouth-quit.service.
and then I’m not able to edit the service.
I’m missing something for sure!
reload PATTERN...
Asks all units listed on the command line to reload their
configuration. Note that this will reload the
service-specific configuration, not the unit configuration
file of systemd. If you want systemd to reload the
configuration file of a unit, use the daemon-reload command.
In other words: for the example case of Apache, this will
reload Apache's httpd.conf in the web server, not the
apache.service systemd unit file.
This command should not be confused with the daemon-reload
command.
So, I would say that systemctl reload is not what you are looking for, right?
systemctl daemon-reload should suffice, but I would ask myself what we expect from the daemon-reload in this case. More on that below.
As for this error, I would say that this is related to the fact that the plymouth-quit.service doesn’t have an ExecReload= entry (systemd.service(5) - Linux manual page), so the job can’t reload. But I am just guessing!
About trying to reload the plymouth-quit.service (e.g. with systemctl daemon-reload): what is the expectation? I would only try to check the results of my modifications to it upon the next reboot, when I would be able to check my changes (hopefully) taking effect. Does it makes sense to you? Let us know if you understand otherwise
Sorry for the late response but I would be sure of what I report to you.
It seems to me that the edits I made by using sudo systemctl edit --full plymouth-quit.service
Are not take into account by the system, even after a systemctl daemon-reload or a system reboot.
Your hint systemctl reload does not seem a correct command, the system responses Too few arguments.
I repeat myself, I am not able to let the system take the change in the service.
Even if I edit the plymouth-quit.service, reboot etc, the content of /usr/lib/systemd/system/plymouth-quit.service does not change at all.
In fact, when I run sudo systemctl edit --full plymouth-quit.service, I see the service in a sort of ‘temporary’ change:
I believe there is a misunderstanding. The service in /usr/lib is the original service that came with the image. When you run sudo systemctl edit --full plymouth-quit.service this creates an override file in /etc/systemd. This override file takes precedence over the original file. But it does not edit or remove the actual original service.
You can see which file systemd considers by running systemctl cat <service-name>. Also I can confirm modifying this service has an effect on when the splash screen exits. Adding docker-compose.service to After does seem to better align the exiting of the splash screen with the start of my graphical container more closely. That said After only waits for the listed services to finish starting. I don’t think it actually waits for said services to be done. So if your container naturally takes a long time to start/show something then that’s another thing.
If you want something more extreme to test your changes you can do something like this:
By adding a sleep like this I was able to observe the splash screen stay up for much longer. My graphical container even started and the splash screen was still running in the background. As a side-note if you do something like this make sure your timeout is longer than your sleep. Otherwise the service will timeout and the splash screen will never exit and the login prompt on serial debug will never come up. Though you can still SSH in and fix the service.
Hi @jeremias.tx , thanks for the detailed explanation. Now everything is clear.
Trying you example, I figured out why I did’t recognize that my changes on the plymouth-quit.service were in fact correctly applied by the system after a reboot (as you point out, a reboot is sufficient to get the system apply my changes).
See the attached systemd-analyze plot > chain.svg output (In which I delayed a lot both plymouth-quit.service and plymouth-quit-wait.service ) chainn.zip (19.1 KB)
As you can see, both service are correctly delayed but again, when I start the board, I see the splash screen, then blue screen (weston container starting) and the chromium starting.
I figured out that, when weston starts, it comes above the splashscreen. Indeed, if I stop all containers during the ‘delayed time’, I can see that below the weston/chromium container the splash screen is again there, until the service reaches the sleep time, the splash screen goes off and remains only a black screen.
So, my problem here is that seems that plymouth is not able to stay foreground.
Thanks again for your help
So, my problem here is that seems that plymouth is not able to stay foreground.
Well achieving this may be a bit tough. I don’t see any option to make the Plymouth splash screen stay in the foreground. From the perspective of Plymouth another graphical process has taken over (weston in this case). But you want the full graphical process to take over not just the weston start-up. Though to plymouth it doesn’t matter as all graphical process have foreground priority, there’s no sense of the “right” graphical process.
There is some way to ‘keep weston minimized’ or something like this for a certain time?
For my use case, I need to hide every weston/chromium loading to get the user a good UX
There is some way to ‘keep weston minimized’ or something like this for a certain time?
I’m not aware there is something like this that would allow the splash screen to continue. If you want to mask the Weston start-up process. Could you not just change the background image/wallpaper of Weston to something more suitable than just a blue screen? Could have some kind of loading-type image or something similar. In the weston.ini there is a property called background-image that you can pass an image file to.
