Since an update I did last night before I wanted to go to sleep, the plasma desktop takes a very long time to build up, i.e. the time from logging in is now significantly longer (splash-screen).
Find someone to blame by:
[vidar@arch-pc ~]$ systemd-analyze blame 2.769s systemd-random-seed.service 1.090s email@example.com 488ms dev-sda2.device 355ms power-profiles-daemon.service 261ms NetworkManager.service 244ms systemd-logind.service 238ms udisks2.service 225ms systemd-fsck@dev-disk-by\x2duuid-caf40634\x2d610f\x2d4992\x2db2db\x2d16d556eaf403.service 158ms polkit.service 158ms ldconfig.service 135ms lvm2-monitor.service 129ms systemd-journal-flush.service 81ms systemd-udevd.service 78ms boot-efi.mount 74ms systemd-udev-trigger.service 60ms systemd-tmpfiles-setup.service 57ms systemd-journald.service 56ms systemd-timesyncd.service 53ms upower.service 52ms systemd-tmpfiles-clean.service 51ms home.mount 46ms avahi-daemon.service 44ms systemd-fsck@dev-disk-by\x2duuid-E31A\x2d3DC3.service 30ms systemd-tmpfiles-setup-dev.service 30ms systemd-journal-catalog-update.service 27ms systemd-modules-load.service 23ms systemd-sysusers.service 13ms firstname.lastname@example.org 13ms alsa-restore.service 12ms systemd-remount-fs.service 11ms dev-hugepages.mount lines 1-31
As far as I can do anything at all with this list: are these values normal, or does
email@example.com take too much time?
no, looks fine actually
I mean, mine
firstname.lastname@example.org is 100ms, but 1s is not…THAT much, in all scheme of things combined
Are all boots longer, or just one after update?
What if you disabled the splash-screen?
All reboots, whether with LTS kernel or current kernel.
How can I do that? I will try that this afternoon, now I have to go away first.
In the System Settings, search splash screen.
It should be somewhere under startup and shutdown if I remember correctly.
No improvement without spash-screen. Same duration until the desktop. The desktop is also no longer displayed animated, but abruptly. Compositor is running though.
For a usefull report use
[vidar@arch-pc ~]$ 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.889s └─multi-user.target @1.889s └─power-profiles-daemon.service @1.621s +267ms └─basic.target @1.606s └─sockets.target @1.606s └─dbus.socket @1.606s └─sysinit.target @1.604s └─systemd-timesyncd.service @1.478s +126ms └─systemd-tmpfiles-setup.service @1.407s +65ms └─local-fs.target @1.404s └─home.mount @1.335s +68ms └─systemd-fsck@dev-disk-by\x2duuid-caf40634\x2d610f\x2d4992\x2db2db\x2d16d556eaf403.servi> └─dev-disk-by\x2duuid-caf40634\x2d610f\x2d4992\x2db2db\x2d16d556eaf403.device @810ms lines 1-16/16 (END)
What you find as a delay is not covered by systemd-analyze reports.
Maybe there is something usefull in the user session
systemd-analyze --user critical-chain
Next, you can just blame Plasma
Also check journal for error messages
Not sure, but could looking into what got updated give some clue?
I already checked https://archlinux.org/ for the latest stuff, but I couldn’t find anything there that would have given me a clue. Yesterday evening, I honestly did not pay much attention to what came in … bad mistake, I know …
You could look at
Hm …, in the meantime I have here now again the normal state. Strange … KDE surprise egg?
Here’s mine on KDE Plasma if you want to compare?
[ricklinux@eos-kde ~]$ 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.664s └─multi-user.target @1.664s └─cups.service @1.591s +72ms └─network.target @1.590s └─NetworkManager.service @1.509s +80ms └─dbus.service @1.508s └─basic.target @1.506s └─sockets.target @1.506s └─dbus.socket @1.506s └─sysinit.target @1.503s └─systemd-update-done.service @1.500s +3ms └─ldconfig.service @1.265s +234ms └─local-fs.target @1.265s └─boot-efi.mount @1.176s +88ms └─systemd-fsck@dev-disk-by\x2duuid-5D81\x2d5E7E.service @458ms +21ms └─dev-disk-by\x2duuid-5D81\x2d5E7E.device @458ms [ricklinux@eos-kde ~]$
Here is mine for KDE Plasma:
systemd-analyze blame 21.132s dev-sda2.device 18.331s systemd-remount-fs.service 2.737s systemd-journal-flush.service 2.512s accounts-daemon.service 2.357s udisks2.service
Do you think it is taking a long time due to the HD?
If I am not mistaken, the delay was between the login screen and the desktop showing up. The startup time of the systemd services will not have any bearing on that as mentioned also above by
The system runs on SSD for me, only the configs in /home are on a HDD. But anyway, I have not changed anything in the meantime.