[SOLVED] Slow Startup Time - systemd-random-seed.service

broms · 2019-09-12 22:40:39

I lost power during an upgrade and the system was un-bootable. I chrooted into the system from a recovery disk and finished the upgrade. Now I can boot into my system and after everything loads, it's all good.

The only problem is boot times are considerably longer than before this happened.

$ systemd-analyze
Startup finished in 1.766s (kernel) + 1min 11.503s (userspace) = 1min 13.270s
graphical.target reached after 7.369s in userspace

$ systemd-analyze blame
1min 11.221s systemd-random-seed.service
     5.470s nmb.service  
....

All my other units are loading in under 4 seconds.
Any idea why systemd-random-seed is taking so long to load and how to bring it back to its peppy old self?

Last edited by broms (2019-09-13 02:12:19)

loqs · 2019-09-12 22:41:37

https://bugs.archlinux.org/task/63738

judd1 · 2019-09-12 22:47:37

sudo paccache -d

du /var/log/journal -h

?

loqs · 2019-09-12 22:52:25

@judd1 how is disk usage related to the increased time systemd-random-seed.service takes to complete?

judd1 · 2019-09-12 22:57:49

@loqs
What I can say from my own experience, is that using some commands like the ones I publish (nothing from another world, obviously) the boot works faster, eliminating cache and too much journal, with more than 100 MB.

Given the bug, what works is to install and enable haveged due to lack of entropy.
https://www.freedesktop.org/software/sy … rvice.html

Last edited by judd1 (2019-09-12 23:09:22)

broms · 2019-09-13 02:11:55

Thank you for the advice, all.

haveged seems to have solved the issue for me.

I had rather low entropy:

# cat /proc/sys/kernel/random/entropy_avail
189

It was un-bootable and sitting off for several weeks. Would this have caused the reduced entropy?

Either way, after

sudo pacman -S haveged
sudo systemctl start haveged
sudo systemctl enable haveged

I'm seeing much lower boot times similar to what I had before:

 $ systemd-analyze
Startup finished in 1.724s (kernel) + 8.085s (userspace) = 9.810s
graphical.target reached after 8.083s in userspace

I just tried with rngd instead of haveged, and that shaves off nearly another second.

Im3rik · 2019-11-10 00:00:57

I had a similar issue on a clean arch installation on both my laptop and all my VMs. systemd-random-seed.service increased my boot time by about 20 seconds essentially tripling it.
I had a hard time finding a proper solution so I thought I should post my solution here as this is the first thread I find on Google.

TL;DR
If you're using kernel 4.19 or newer add random.trust_cpu=on to the kernel command line in your bootloader (speeded up the load time of this service from about 20s to 5ms on my system).
If not try using rng-tools or if that doesn't work use haveged.

First I should say that I'm not an expert in cryptography, so consider doing your own research. Please feel free to tell me if something isn't correct.

So basically what slows down the boot sequence is systemd accessing the pseudorandom number generator /dev/random during boot, because /dev/random blocks if there is not enough entropy (basically collected random noise) available and waits until there is enough available.

How is entropy generated? The kernel collects random noise from hardware random number generators like keyboard input, mouse input and most importantly (because it's the fastest) the CPU.
However because the CPU hardware random number generator could possibly be compromised (search for "RDRAND NSA" in the search engine of your choice) there is a compile option for the linux kernel that tells it not to trust the CPU generated random numbers. In the Arch kernel (at least in 5.3.8 that I'm using) this option is not set and therefore defaults to no (not trusting the CPU).
So the kernel will only collect entropy from other much slower sources causing /dev/random to block during boot until enough entropy is collected.

With kernel 4.19 and above there's the command line option random.trust_cpu to change this behavior without needing to recompile the kernel.

So why should I trust the CPU then? Well, Linus Torvalds said that even if the CPU is trusted the entropy will still contain some data from other sources and (that's the part I'm not sure about) as far as I know it should be pretty hard for an attacker who compromised the CPU random number generator to compromise /dev/random. If you're concerned about that you should probably better wait 20 seconds longer.

Some cryptography experts recommend not using haveged if you could use another hardware based generator like RDRAND, but if you're on a headless server that doesn't generate much entropy without it, this could be your best option.

Last edited by Im3rik (2019-11-10 00:01:34)

Arch Linux

#1 2019-09-12 22:40:39

[SOLVED] Slow Startup Time - systemd-random-seed.service

#2 2019-09-12 22:41:37

Re: [SOLVED] Slow Startup Time - systemd-random-seed.service

#3 2019-09-12 22:47:37

Re: [SOLVED] Slow Startup Time - systemd-random-seed.service

#4 2019-09-12 22:52:25

Re: [SOLVED] Slow Startup Time - systemd-random-seed.service

#5 2019-09-12 22:57:49

Re: [SOLVED] Slow Startup Time - systemd-random-seed.service

#6 2019-09-13 02:11:55

Re: [SOLVED] Slow Startup Time - systemd-random-seed.service

#7 2019-11-10 00:00:57

Re: [SOLVED] Slow Startup Time - systemd-random-seed.service

Board footer