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:
systemd-analyze blame
[vidar@arch-pc ~]$ systemd-analyze blame
2.769s systemd-random-seed.service
1.090s user@1000.service
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 modprobe@fuse.service
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 user@1000.service take too much time?
no, looks fine actually 
I mean, mine user@1000.service 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.
Choose none.
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
systemd-analyze critical-chain[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?
1 Like
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 /var/log/pacman.log.
1 Like
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 ~]$
1 Like
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 @petsam.
2 Likes
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.