Slow boot due to userspace processes

System is stable branch, Kernel is 5.8.6.1 KDE Plasma 5.19.5 NVidia graphics and driver. Spinning drive. Mature system. Sudo systemd-analyze time yields 13.4 sec for kernel plus an astounding 1 minute 31.404 seconds userspace processes. Dunno whats going on in userspace but question which tools to use to find out what in userspace is so slow at startup…
Thanks

You can start by issuing

systemd-analyze blame

and

systemd-analyze critical-chain

1 Like

Hi Jabber. thanks.
systemd-analyze critical-chain yields

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.

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 31.403s
multi-user.target 31.403s
maldet.service 23.606s +7.796s
network.target 23.410s
NetworkManager.service 21.018s +2.392s
dbus.service 21.016s
basic.target 21.010s
sockets.target 21.010s
org.cups.cupsd.socket 21.010s
sysinit.target 20.972s
sys-fs-fuse-connections.mount 44.951s +1ms
└─systemd-modules-load.service 1.468s +3.341s
└─systemd-journald.socket 1.390s
└─-.mount 1.268s
└─system.slice 1.268s
└─-.slice 1.268s
Had to do away with the ampersands after I was told I could only mention 10 users in a chain

systemd-analyze blame
7.884s systemd-journal-flush.service
9.930s lvm2-monitor.service
9.179s dev-sda1.device
7.796s maldet.service
5.879s polkit.service
4.690s systemd-sysusers.service
4.552s systemd-hwdb-update.service
3.962s udisks2.service
3.341s systemd-modules-load.service
2.995s ldconfig.service
2.916s packagekit.service
2.838s accounts-daemon.service
2.692s systemd-udevd.service
2.548s ModemManager.service
2.394s avahi-daemon.service
2.392s NetworkManager.service
2.004s org.cups.cupsd.service
1.986s systemd-logind.service
1.267s upower.service
1.233s tlp.service
989ms systemd-tmpfiles-setup-dev.service
986ms user@1000.service
924ms systemd-tmpfiles-setup.service
777ms systemd-resolved.service
595ms lightdm.service
574ms swapfile.swap
438ms systemd-random-seed.service
423ms lm_sensors.service
413ms alsa-restore.service
410ms ntpd.service
396ms modprobe@drm.service
321ms systemd-timesyncd.service
315ms systemd-journald.service
287ms systemd-udev-trigger.service
167ms systemd-sysctl.service
146ms kmod-static-nodes.service
121ms systemd-update-done.service
99ms systemd-binfmt.service
98ms mnt-3725d9eb\x2dfe2f\x2d4747\x2d8b7a\x2d9962c6936ddf.mount
93ms systemd-journal-catalog-update.service
79ms dev-hugepages.mount
78ms systemd-update-utmp.service
76ms dev-mqueue.mount
73ms sys-kernel-debug.mount
70ms sys-kernel-tracing.mount
57ms systemd-user-sessions.service
42ms systemd-remount-fs.service
33ms rtkit-daemon.service
27ms sys-kernel-config.mount
24ms user-runtime-dir@1000.service
8ms tmp.mount
5ms proc-sys-fs-binfmt_misc.mount
1ms sys-fs-fuse-connections.mount

I think that may be typical for a spinning disk. The system is going to be trying to load a bunch of stuff at once into memory, and that means lots of small random reads which is what spinning disks perform worst at.

1 Like

Hi yosukemat

I fear you may be correct.
thanks