Some Systemd services are taking quite a bit longer to start than before

Support
1

I’ve noticed that some Systemd services are taking quite a bit longer to start now.
These two are the top of my systemd-analyse blame:

1.546s systemd-modules-load.service
1.304s systemd-random-seed.service

Only /etc/modules-load.d/mhwd-gpu.conf is loaded, no? My /etc/modules-load.d/modules.conf is empty.
I didn’t even notice that my boot times were longer. Just happened to check, since I haven’t run the command in a while. :grin:

2

Contents of /etc/modules-load.d/mhwd-gpu.conf:

##
## Generated by mhwd - Manjaro Hardware Detection
##
 
nvidia
nvidia-drm

This file has been in my system since February 3rd, while the system is two years old.
Here’s what the service tells me:

systemctl status systemd-modules-load.service                                                                                                                                                                                                 ✔ 
● systemd-modules-load.service - Load Kernel Modules
     Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
     Active: active (exited) since Fri 2022-06-10 10:30:45 EEST; 6h ago
       Docs: man:systemd-modules-load.service(8)
             man:modules-load.d(5)
    Process: 347 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
   Main PID: 347 (code=exited, status=0/SUCCESS)
        CPU: 1.432s

kesä 10 10:30:43 jp-gentoo systemd-modules-load[347]: Inserted module 'crypto_user'
kesä 10 10:30:43 jp-gentoo systemd-modules-load[347]: Inserted module 'sg'
kesä 10 10:30:43 jp-gentoo systemd-modules-load[347]: Inserted module 'ipmi_devintf'
kesä 10 10:30:44 jp-gentoo systemd-modules-load[347]: Inserted module 'nvidia'
kesä 10 10:30:44 jp-gentoo systemd-modules-load[347]: Inserted module 'nvidia_drm'
kesä 10 10:30:45 jp-gentoo systemd-modules-load[347]: Inserted module 'nvidia_uvm'
kesä 10 10:30:45 jp-gentoo systemd-modules-load[347]: Inserted module 'uinput'
kesä 10 10:30:45 jp-gentoo systemd[1]: Finished Load Kernel Modules.
Notice: journal has been rotated since unit was started, output may be incomplete.

Is this normal?
Random seed service doesn’t take an unusally long time to start anymore.

3

Sure, why wouldn’t it be?

4

So the service taking this long to load is normal? I see many users on this forum where it takes 1/10 of the time to load.

5

I’m trying to understand what the concern is? Where is the actual problem?

6

I try to understand why systemd-modules-load.service takes one and a half seconds to load, which hasn’t been the case in the past. And if this is normal behaviour for this service.

7

Here’s mine, if it means anything.

I’m “winning” by 0.246 seconds! :muscle:

1.300s systemd-modules-load.service

This allows me to cook my food and enjoy my breakfast just a bit longer, in all the time I saved not waiting for systemd-modules-load.service to take precious moments from my glorious life.

1 Like
8

Good to know that it might be normal.
I tried browsing the forums, but only saw similar times with people who had problems with other services taking 10 seconds or more to load :+1:

9

I’m jealous of you, because you’re winning by a larger margin with your godlike random seed generation speeds!

1.884s systemd-random-seed.service

Life is not fair! :sob:

10

It has gotten much much lower since I made that post:

6ms systemd-random-seed.service
11

54ms systemd-modules-load.service :man_shrugging:

12

Basically mwhd will load your GPU drivers, and I should say AMD drivers are loading as fast as 100-200 ms, and random seed is faster on better cpu systems (as it is faster calculating it), or when you do your randomness by pressing random keys and moving your mouse. I saw that linux also uses this in random number generator to be more random.

13

Just Nvidia Things™ then, I guess :face_exhaling:

It really sticks out 
1.676s systemd-modules-load.service
 329ms dev-sda2.device
 191ms tlp.service
 129ms systemd-journal-flush.service
 107ms apparmor.service
  93ms ModemManager.service
  89ms systemd-udev-trigger.service
  89ms ldconfig.service
  85ms user@1000.service
  79ms lm_sensors.service
  79ms polkit.service
  68ms lvm2-monitor.service
  63ms systemd-udevd.service
  53ms avahi-daemon.service
  49ms dbus.service
  47ms boot-efi.mount
  47ms systemd-logind.service
  43ms udisks2.service
  41ms systemd-resolved.service
  41ms cups.service
  35ms NetworkManager.service
  32ms systemd-sysusers.service
  32ms systemd-journald.service
  31ms systemd-tmpfiles-clean.service
  29ms upower.service
  27ms systemd-tmpfiles-setup.service
  24ms systemd-timesyncd.service
  24ms systemd-tmpfiles-setup-dev.service
  23ms systemd-fsck-root.service
  17ms systemd-fsck@dev-disk-by\x2duuid-B5D2\x2d5542.service
  17ms systemd-fsck@dev-disk-by\x2duuid-9477a9d1\x2d47fc\x2d4f4b\x2da05f\x2d24cd2755ab8e.service
  15ms mnt-faaast.mount
  14ms pamac-daemon.service
  12ms modprobe@fuse.service
   8ms alsa-restore.service
   7ms dev-hugepages.mount
   7ms dev-mqueue.mount
   7ms systemd-journal-catalog-update.service
   7ms sys-kernel-debug.mount
   6ms sys-kernel-tracing.mount
   6ms systemd-random-seed.service
   6ms kmod-static-nodes.service
   6ms modprobe@drm.service
   6ms modprobe@configfs.service
   5ms systemd-remount-fs.service
   5ms linux-module-cleanup.service
   5ms systemd-binfmt.service
   4ms systemd-update-utmp.service
   4ms mnt-faaast-swap.swap
   3ms user-runtime-dir@1000.service
   2ms systemd-sysctl.service
   2ms systemd-user-sessions.service
   2ms systemd-update-done.service