How to install systemd-analyze ?

[stuarte]

Good afternoon all,

Could someone please tell me how to install systemd-analyze ? I have tried using :-
a) Discover but it could not find the package;
b) Muon Package Manager, but the package list area just goes blank when I type "systemd-ana" (without the quotes);
c) sudo apt-get install systemd-analyze, but it just states :-

$ sudo apt-get install systemd-analyze
[sudo] password for kub:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package systemd-analyze

So, just how do I install this package on Kubuntu 22.04.3 ?

Stuart

[claydoh]

It is already included, as part of systemd as a whole, not a separate package.

Just run the command systemd-analyze, and/or systemd-analyze blame, and systemd-analyze critical-chain to see some interesting boot info.

[stuarte]

Good evening,

claydoh: I will try to use your suggestions either tomorrow afternoon or on Friday. I can't do it tomorrow morning as I help out at food bank at my local church.

[stuarte]

Good afternoon,

claydoh: when I try to run systend-analyse, the system responds as shown below.



What now ?

[claydoh]

Good afternoon,

claydoh: when I try to run systend-analyse, the system responds as shown below.



What now ?

it is easier to copy and paste the text, highlight/select it, and use the "#" button in the text editor, for this sort of action. It can be hard or awkward to view the text in an image, especially on mobile.

But, you need to use a 'z' instead of an 's' in systemd-analyze, as the message suggests.

[stuarte]

Good afternoon,

claydoh: PLease accept my apologies for not "getting it right" yet again.

Now to the real business. I have just completed the kernel swap from hwe kernel to generic GA kernel. I then performed the systemd-analyze (with a "z" ) and generated a bootchart type image file (see attached file bootupchart.svg). Could someone vastly more experienced with/knowledge of systend-analyze than I have a look at the attached file and see if anything immediately "jumps out" and looks "out-of-place ?

[claydoh]

Paste the output of systemd-analyze then systemd-analyze blame, and systemd-analyze critical-chain, and use the code button (#)
It is easier to see more direct info for this than the image.



For the 'blame' command, hit the 'q' button to exit, and just copy the first 10-15 lines or so.


Here is mine, for example:

$ systemd-analyze
Startup finished in 10.091s (firmware) + 2.762s (loader) + 3.547s (kernel) + 1.246s (userspace) = 17.647s
graphical.target reached after 1.217s in userspace​

$ systemd-analyze blame
2.643s mnt-Stuff.mount
313ms networkd-dispatcher.service
308ms dev-loop1.device
308ms dev-loop0.device
307ms dev-loop2.device
306ms dev-loop3.device
300ms apt-daily-upgrade.service
298ms libvirt-guests.service
293ms systemd-journal-flush.service
230ms user@1000.service
209ms dev-nvme0n1p2.device
154ms mnt-Backups.mount
124ms neon-apt-mark-kernels-auto.service
118ms systemd-resolved.service
109ms logrotate.service
​

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1.217s
└─multi-user.target @1.217s
└─libvirt-guests.service @918ms +298ms
└─libvirtd.service @863ms +52ms
└─remote-fs.target @859ms
└─remote-fs-pre.target @858ms
└─rpcbind.service @660ms +94ms
└─systemd-tmpfiles-setup.service @651ms +7ms
└─local-fs.target @615ms
└─media-claydoh-Games.mount @528ms +86ms
└─dev-nvme1n1p1.device @520ms

This process just shows how long things are taking during the boot process. Many things are started in parallel, so the values can be a little deceiving.
Interesting, but generally not useful other than diagnosing slowe than usual boot times, or for those who tweak All The things
Are you having issues with long boot times?

In my example, my PC takes 10 seconds to get past the POST/bios 'splash' screen (the "firmware" part) before it even gets to grub ("loader"), and takes a total of 17.6 to get to the desktop from powering on.
I can't change the firmware time to speed it up (already set to 'fast')
One of my drives is taking 2.6 seconds to mount in the middle of this ( which really isn't having an effect on the total boot time)

The critical chain part shows which things are sort of adding time to the boot process. The entries with the "+xxx ms".

[stuarte]

Good afternoon,

claydoh: Here are my outputs from systemd-analyze.

$ systemd-analyze
Startup finished in 6.870s (kernel) + 41.701s (userspace) = 48.572s
graphical.target reached after 41.667s in userspace​

$ systemd-analyze blame
18.090s snapd.service
16.567s e2scrub_reap.service
14.683s networkd-dispatcher.service
12.865s udisks2.service
12.195s logrotate.service
9.490s NetworkManager-wait-online.service
8.522s accounts-daemon.service
7.807s NetworkManager.service
7.462s power-profiles-daemon.service
7.411s polkit.service
7.383s plymouth-read-write.service
7.350s ModemManager.service
6.614s avahi-daemon.service
6.609s bluetooth.service
6.071s thermald.service
6.069s systemd-logind.service​

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @41.667s
└─multi-user.target @41.667s
└─snapd.seeded.service @38.170s +3.496s
└─snapd.service @20.041s +18.090s
└─basic.target @19.482s
└─sockets.target @19.482s
└─cups.socket @23.619s
└─sysinit.target @19.365s
└─plymouth-read-write.service @11.981s +7.383s
└─local-fs.target @11.957s
└─home.mount @11.537s +420ms
└─systemd-fsck@dev-disk-by\x2duuid-05fc8b81\x2da330\x2d4c74\x2d91ed\x2d77f37aa16a9c.s ervice @9.357s +2.122s
└─dev-disk-by\x2duuid-05fc8b81\x2da330\x2d4c74\x2d91ed\x2d77f37aa16a9c.d evice @9.323s​

[claydoh]

The items with a '+' and a time are waht are slowing things down, or taking a while, and preventing other services from starting right away.
One is obviously related to Snap loading stuff, that is known to do this if one has a LOT of snap applications, and/or an older, slower machine, with a slower spinning hard drive.

But also something related to plymouth (your splash screen between grub and the login) and one drive seeing a disc check (fsck)
I don't know what plymouth-read-write.service is, and haven't quickly located much on this item to be able to give any useful ideas.

Do this same set of commands after your next boot, and compare - the drive check might be a regular check, or it might indicate an issue

[stuarte]

Good morning,

Her are this mornings systemd-analyze outputs generated immediately after the initial cold boot.

$ systemd-analyze
Startup finished in 7.357s (kernel) + 39.964s (userspace) = 47.321s
graphical.target reached after 39.917s in userspace

$ systemd-analyze blame
20.586s e2scrub_reap.service
15.070s snapd.service
11.203s NetworkManager-wait-online.service
10.918s udisks2.service
9.904s networkd-dispatcher.service
9.022s accounts-daemon.service
6.681s power-profiles-daemon.service
6.575s polkit.service
6.480s ModemManager.service
5.721s smartmontools.service
5.130s cups.service
5.111s plymouth-read-write.service
4.958s NetworkManager.service
4.942s avahi-daemon.service
4.939s bluetooth.service
4.230s dev-sda9.device
4.208s dev-sda8.device
3.946s packagekit.service
3.728s systemd-fsck@dev-disk-by\x2duuid-05fc8b81\x2da330\x2d4c74\x2d91ed\x2d77f37aa16a9c.s ervice
3.464s thermald.service​

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @39.917s
└─multi-user.target @39.917s
└─snapd.seeded.service @35.877s +3.217s
└─snapd.service @20.779s +15.070s
└─basic.target @19.281s
└─sockets.target @19.280s
└─snapd.socket @19.257s +22ms
└─sysinit.target @19.159s
└─plymouth-read-write.service @14.047s +5.111s
└─local-fs.target @14.015s
└─home.mount @13.635s +379ms
└─systemd-fsck@dev-disk-by\x2duuid-05fc8b81\x2da330\x2d4c74\x2d91ed\x2d77f37aa16a9c.s ervice @9.742s +3.728s
└─dev-disk-by\x2duuid-05fc8b81\x2da330\x2d4c74\x2d91ed\x2d77f37aa16a9c.d evice @9.694s​

I note that, in post #8, under

systemd-analyze blame

, that

plymouth

was started immediately after

polkit.service

. This time, under

systemd-analyze blame

,

plymouth

was started immediately after

cups.service

. When

plymouth

starts may have a bearing on the (non)appearance or those "k"s during bootup.

I did a web search for plymouth and found the following.

https://wiki.ubuntu.com/Plymouth

I will be spending this morning, if not all day, investigating the files mentioned therein, particularly those mentioned in the "Startup" section.

ASIDE: It is interesting to note that the bootup with an hwe kernel was intruded upon by the appearance of the "^[k" string (without quotes) whereas currently with a GA kernel this has reverted to the "k" character (also without quotes).

I am currently using Kompare to highlight the differences between (source file) systemd_analyze_outputs.txt (i.e. the major contents of post #8) and (destination file) second_systemd_analyze_outputs.txt (i.e. the major contents of this post shown above). These seem to clearly imply that there is no repeatability within the boot up order meaning that files/services seem to be able to be started in a somewhat random order. Shouldn't files/services be started in the same order each time, thereby imparting stability to the system ?

Lastly (for this post ), things have taken a bad turn. If I don't use the external keyboard for a few minutes, this keyboard is then no longer recognised. Also, in the case when the external keyboard is still recognised, if I press a key on the laptop keyboard (which displays no response on the screen) and then press a key on the external keyboard, the latter is no longer recognised.

As the situation is somewhat in flux, perhaps I should start a new post/thread. This could lead to more than one thread dealing with this same problem. What do you think ?