I’ve seen in various forum posts that updatedb.service and man-db.service appear in the output of systemd-analyze. I know the very first time updatedb runs it takes longer, but otherwise it is pretty fast. My question is NOT about these two services, but about systemd boot.
Why are these two services running at bootl? Is there a timer option to say not at boot?
The whole initial thing about systemd replacing SysVinit was parallelizing for a “faster” boot. When I view the output that users are posting on this forum from systemd-analyze blame, it doesn’t appear that is happening, or am I missing something? If there are 5 services that run 1 minute each, the completion time isn’t 5 minutes, it’s still 1. I’m still getting the hang of systemd.
They will only run at boot if the system was down overnight. They are supposed to run around midnight, but if the computer was down, then they will be run upon the next boot.
Some services depend upon other services being up and cannot carry on until their dependency is met, and so the whole parallelization thing should be taken with a grain of salt.
The problem with systemd-analyze blame is that it does not show at which time the GUI is really usable. For systemd the boot is complete after all services that had to be started are started and sometimes finished (depends on the service) . But for a user the boot is complete at the time the login screen appears. At this time, the boot is for systemd not finished.
I think I understand what you are saying. When a user sees the graphical logon prompt, systemd could still be working its’ way through the various services (in parallel). The blame option could show a service (like man-db or updatedb) at the top of the output, but those services at the top might not have any impact on when the user can actually logon. It seems like this is where the option critical-chain might be helpful, because it might show the service that is blocking.
In a way, I like the overview of systemd-analyze time, where the user only see the times for firmware, loader, kernel, userspace. I’m assuming graphical.target reached is when the user sees the logon prompt.
No unfortunately not. The graphical.target is on a GUI system the default target. Also a target is reached after all services that are part of this target are finished starting. The graphical.target is called “graphical” to distinguish it from the “multi-user.target” but it is not reached with the pop up of the login screen.
Maybe to visualize it a little better use the plot option. You can also see which services are started parallel and which services holt the boot up.
systemd-analyze plot > plot.svg
(The svg file can sometimes not opened with image viewer, try a browser)
You can use more precise selection for a service you’re interested in like systemd-analyze blame sddm.service. And critical-chain too, if I’m not mistaken.
