Improving boot time

Bluboy234 · 2022-03-15 14:03:46

I am running KDE on 5.15.28.1-lts kernel. I know my system is not slow but I have read about other arch users with way faster systems. So I want to know if there are any improvments I can make. I think systemd-random-seed.service may be little slow as well.
I looked a bit by myself and found that start time of systemd-random-seed.service in seconds is not a good thing. (it should be in Millisecs)

Output of systemd-analyze

Startup finished in 3.375s (firmware) + 966ms (loader) + 1.396s (kernel) + 4.453s (userspace) = 10.192s 
graphical.target reached after 4.065s in userspace

Output of systemd-analyze blame

3.672s systemd-random-seed.service
1.563s netctl@wlp2s0\x2dnet_5g.service
1.062s dev-sda8.device
 386ms tlp.service
 230ms ufw.service
 211ms lvm2-monitor.service
 209ms ldconfig.service
 208ms boot.mount
 139ms upower.service
 121ms user@1000.service
  88ms systemd-fsck@dev-disk-by\x2duuid-EA4E\x2d818A.service
  86ms systemd-tmpfiles-setup.service
  83ms systemd-udev-trigger.service
  69ms polkit.service
  69ms systemd-logind.service
  67ms udisks2.service
  62ms systemd-udevd.service
  57ms systemd-journal-flush.service
  47ms systemd-journald.service
  38ms systemd-timesyncd.service
  36ms systemd-sysusers.service
  35ms bluetooth.service
  28ms systemd-tmpfiles-setup-dev.service
  27ms systemd-tmpfiles-clean.service
  23ms dbus.service
  17ms systemd-binfmt.service
  17ms systemd-journal-catalog-update.service
  16ms modprobe@fuse.service
  15ms systemd-modules-load.service
  13ms systemd-backlight@leds:kbd_backlight.service
  13ms dev-hugepages.mount
  12ms dev-mqueue.mount
  12ms sys-kernel-debug.mount
  11ms sys-kernel-tracing.mount
  10ms kmod-static-nodes.service
   9ms modprobe@configfs.service
   9ms modprobe@drm.service
   9ms systemd-sysctl.service
   9ms systemd-update-utmp.service
   8ms sys-kernel-config.mount
   8ms dev-disk-by\x2duuid-753adafe\x2d7a05\x2d4d8e\x2d9370\x2da47856e004b3.swap
   6ms systemd-remount-fs.service
   6ms systemd-rfkill.service
   6ms user-runtime-dir@1000.service
   4ms systemd-backlight@backlight:intel_backlight.service
   4ms systemd-update-done.service
   4ms systemd-user-sessions.service
   3ms proc-sys-fs-binfmt_misc.mount
   3ms rtkit-daemon.service
   3ms sys-fs-fuse-connections.mount
   3ms alsa-restore.service
   2ms tmp.mount

Output of 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 @4.065s
└─sddm.service @4.065s
  └─systemd-user-sessions.service @4.060s +4ms
    └─network.target @4.058s
      └─netctl@wlp2s0\x2dbluie_5g.service @2.495s +1.563s
        └─sys-subsystem-net-devices-wlp2s0.device @2.494s

Trilby · 2022-03-15 14:37:31

The random seed time does seem long, but as it's not in the critical chain, reducing it's time will not impact your use.

Having graphical sessions depend on networking being up is absolutely absurd (though typical now with the big DEs). If you can remove the dependence on the network.target you'll gain 4 seconds.

This could be done in one of several ways including overrides for the "After=" line of systemd-user-sessions or sddm.

Last edited by Trilby (2022-03-15 14:40:58)

Raynman · 2022-03-15 15:18:31

network.target shouldn't do much; what is netctl doing? network-online.target can take a while and ordering user sessions after that does sound absurd, but if netctl delays network.target until wifi is up with DHCP and everything, that is effectively what you get. Maybe switch to netctl-auto@wlp2s0.service (or another network manager)?

Bluboy234 · 2022-03-15 15:31:21

Trilby wrote:

The random seed time does seem long, but as it's not in the critical chain, reducing it's time will not impact your use.
Having graphical sessions depend on networking being up is absolutely absurd (though typical now with the big DEs). If you can remove the dependence on the network.target you'll gain 4 seconds.
This could be done in one of several ways including overrides for the "After=" line of systemd-user-sessions or sddm.

I never thought about network about that way. So it is possible that my computer connects to network after reaching graphical session (while I am on sddm greeter or maybe my splash screen). I tried to look at etc/systemd/user.conf but could not find any #After line there and what will I have to input in that same line? Can you give more details.

Trilby · 2022-03-15 18:20:25

That's my point, unless your user account is on a network file server, then there's no reason you need networking up and running *before* you log in. But the defaults for most service files requires everything that everyone every *might* need. The dependency on networking is so that it will work out-of-the box on any machine even if the user's account is on a network filesystem.

The "After=" line is in the unit file, not the config file. But you'd not want to edit the distributed unit file but rather create an override for it following the wiki.

Beyond that I can't give too many specfiics as this is one of many reasons I've stayed far away from big DE's or much reliance on systemd complexities. Another way to address this is to configure your networking service to fork / return immediately and not wait for an active connection. This is what I do with the dhcpcd service as noted in the wiki. If there is such an option for your networking tools, that may be the best way to go.

Arch Linux

#1 2022-03-15 14:03:46

Improving boot time

#2 2022-03-15 14:37:31

Re: Improving boot time

#3 2022-03-15 15:18:31

Re: Improving boot time

#4 2022-03-15 15:31:21

Re: Improving boot time

#5 2022-03-15 18:20:25

Re: Improving boot time

Board footer