Bug 118921 - /dev/random runs out of entropy
Summary: /dev/random runs out of entropy
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-22 20:23 UTC by Stefan Neufeind
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-29 20:13:44 UTC
Type: ---

Attachments (Terms of Use)

Description Stefan Neufeind 2004-03-22 20:23:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera 
7.23  [en]

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):

How reproducible:

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 

Additional info:

I believe this bug is quite grave, since it hangs some programs 
completely, which need /dev/random.

Dirty quickfix:
rm /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.

Also see:
which refers to RedHat Enterprise Linux

Comment 1 Leonard den Ottolander 2004-03-25 19:53:19 UTC
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.

Comment 2 Leonard den Ottolander 2004-03-25 20:03:46 UTC
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.

Comment 3 Stefan Neufeind 2004-03-25 23:00:20 UTC
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) :-((

Comment 4 Leonard den Ottolander 2004-03-26 00:40:04 UTC
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?

Comment 5 Stefan Neufeind 2004-03-26 18:38:11 UTC
board: P4B533-V
chipset: Intel 82845G MCH & Intel 82801 ICH4
cpu: Intel PIV 2.4Ghz

Comment 6 Stefan Neufeind 2004-03-31 22:58:49 UTC
also see:

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.

Comment 7 Jim Richard 2004-04-05 01:17:04 UTC
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

Comment 8 Alan Cox 2004-05-03 16:03:51 UTC
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

Comment 9 Aleksander Adamowski 2004-05-04 12:52:59 UTC
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
8506-4LP controller.

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
mor entropy:

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

Comment 10 Aleksander Adamowski 2004-05-04 12:57:35 UTC
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.

Comment 11 Aleksander Adamowski 2004-06-23 12:48:45 UTC
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?

Comment 12 James C. Montz 2004-08-18 21:07:17 UTC
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 
exhaust it.
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 
command line.
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.

Comment 13 David Lawrence 2004-09-29 20:13:44 UTC
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/

Note You need to log in before you can comment on or make changes to this bug.