Re: [bitfolk] rngd using high cpu

Top Page

Reply to this message
Author: Andy Smith
Date:  
To: users
Subject: Re: [bitfolk] rngd using high cpu
Hi Hugh,

On Tue, Sep 01, 2020 at 06:18:19PM +0100, Hugh Frostick wrote:
> I did not start the service myself.
> I don’t know what it is used by or it purpose.


Ah okay. Well I'm not familiar with Virtualmin, and I haven't used
rngd much, but I'm guessing that Virtualmin installed it.

Some background which won't directly address your issue but may help
you on your way…

There was an old misconception on Linux that /dev/random provided
"better" entropy sourced from truly unpredictable things like
hardware interrupts. When /dev/random hasn't got enough input from
random events it blocks until it does.

Virtual machines don't have any hardware to give them these random
inputs, so software configured to use /dev/random or the associated
syscall might stall when trying to do crypto things like generate a
crypto key or accept a TLS connection.

As a result people deployed hacks like running rngd. Amongst other
things what it does is read from /dev/urandom and feed it into
/dev/random. /dev/urandom is like /dev/random but it is constantly
replenished by a pseudorandom number generator so it never blocks.

I said above that this was a misconception. It is, because it's now
widely accepted that Linux was wrong to ever make /dev/random block,
and that there is no meaningful difference between the "quality" of
randomness that comes from urandom vs random. Everything should have
just used urandom in the first place. For more on that, read:

    https://www.2uo.de/myths-about-urandom/


But, possibly you are running software that wants to read
/dev/random, and it starts to block. I do not know if that is the
case. It seems like Virtualmin may have decided you need rngd, or it
may have just installed it for you needlessly.

You could disable it and see if anything slows down. The prime
candidates would be a web server that's serving https or your SSH
server (both need entropy for accepting a connection).

If you disable and shut down rngd and nothing goes wrong then I
guess you can leave it there, or at least investigate at your
leisure.

So, to disable it and shut it down:

# systemctl disable rngd
# systemctl stop rngd

You can monitor how much entropy you have by reading this proc file:

$ cat /proc/sys/kernel/random/entropy_avail
3563

As long as it's always above say, 500, I think you're okay. You can
read it in a loop like this:

$ watch -n 1 cat /proc/sys/kernel/random/entropy_avail

to see it every second. Note that forking a process uses some
entropy, so if you do that every tenth of a second or something you
may actually drain your own entropy just looking at it.

If shutting down rngd does lead to your entropy draining away then
you may want to try and use BitFolk's entropy service or else you'll
need to resolve this issue with rngd more swiftly.

To investigate the issue you're having with rngd you may have to ask
upstream authors, which appears to be here:

    https://github.com/nhorman/rng-tools


Good luck, and please do let us know how you get on!

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting