Red Hat Bugzilla – Bug 118921
/dev/random runs out of entropy
Last modified: 2007-11-30 17:10:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera
Description of problem:
Reads to /dev/random block unexpectedly because there is no entropy
sysctl -A | grep random
kernel.random.entropy_avail = 0
The system is a server, so I can't unfortunately generate keyboard or
mouse "input" to try if entropy is generated again by that. Tried
doing some disc-I/Os by "find / -name abc" or something - but it
didn't help ... maybe cause the filesystem was already completely in
It's an IDE-machine.
Is network not used for entropy? The system is running a network
services, so there is definitely network-traffic.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. dd if=/dev/random of=testfile bs=1 count=1
Actual Results: dd hangs, cause /dev/random does not output anything
(due to missing entropy)
Expected Results: testfile should be written with any random
I believe this bug is quite grave, since it hangs some programs
completely, which need /dev/random.
mknod -m 0444 /dev/random c 1 9
This maps /dev/random to /dev/urandom. It's less secure, but works
for the moment. However, the bug urgently needs fixing if possible.
which refers to RedHat Enterprise Linux
AFAICT /dev/random running out of entropy is expected behaviour. It
needs input for new entropy. This is why /dev/urandom is there.
I would say NOTABUG, but wont close as I am not 100% sure.
man 4 random states:
When the entropy pool is empty, reads from /dev/random will block
until additional environmental noise is gathered.
I.e. known behaviour. Closing NOTABUG.
The blocking is expected - right! But the entropy pool does not fill
again. Using /dev/urandom instead (see the "dirty quickfix" provided)
helps, but degrades security since urandom produces weaker random
bytes (less security) :-((
My mistake. Sorry for that.
So this problem also exists on single CPU FC 1 machines. I cannot
reproduce it easily on my machine, but that is a desktop.
Not sure if it is relevant, but what is your hardware setup?
chipset: Intel 82845G MCH & Intel 82801 ICH4
cpu: Intel PIV 2.4Ghz
it seems to be reproducable for Jim. Maybe it could be reproduced by
stresstesting (exhausting) /dev/random and wait for it to recover?
Unfortunately I don't have test-system at hand right now, but could
somebody with more in-sight-knowledge *please* have a look? The
problem seems to be quite essential imho.
Just want to monitor, I've a similar bug open against RHEL... see
Bug#s 117218 and 119526. This condition is very re-producable on any
system that makes extensive use of SSH, SSL, I also see it on RHEL
clusters since cluster daemons appear to access /dev/urandom.
Also Google search yields a long and disperate list of problems in
this area, try the following search criteria: +linux +/dev/random
One of the problems here is sources of entropy. Not all systems have a
lot of sources - especially those that are not using keyboard/local
disk a lot
I'm having this problem on Fedora Core 1.
CPU: 2 x Xeon 2GHz
Motherboard: Intel SE7501BR2
Storage: Hardware RAID-5 Array of Serial-ATA disks on 3Ware Escalade
Isn't writing to /dev/random supposed to reseed the entropy pool? If
it is, then it doesn't work. When I do the following I don't get any
dd if=./some_binary_file of=/dev/random bs=512 count=1
Also, waiting any amount of time doesn't help, the entropy stays at 0:
$ sysctl kernel.random.entropy_avail
kernel.random.entropy_avail = 0
Also, moving the mouse and tapping keys on the keyboard doesn't fill
the entropy pool - something is clearly wrong.
This is on kernel 2.4.22-1.2188.nptlsmp. I've never seen such things
on this machine with previous Fedora kernel versions, but this might
only be a coincidence.
The problem also occurs on RHEL kernel!
A Fedora Core 1 host running RHEL kernel 2.4.21-15.ELsmp (switched to
RHEL kernel because of bug 123332) has the same problem right now.
Any ideas how to debug it?
Just wanted to share some information with everyone on this issue.
Agreed, that it is ultimately an issue with /dev/random, but I was
curious as to what exactly was using /dev/random so much as to
In our particular instance, we have a Java application that uses SSL
extensively. (Sun J2SDK 1.4.2), which used /dev/random specifically.
There is an option in java.security to specify the "entropy gathering
device", either in java.security, or by overriding the option on the
We have implemented the command line option on the java instance in
question and are currently testing. (-
I will post an update if this ultimately resolves the issue.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/