I have a server that cannot generate enough entropy to support /dev/random. The particular piece of software having problems can't be configured to use /dev/urandom.

I tried moving /dev/random to /dev/realrandom and symlinking /dev/random to /dev/urandom, but lsof /dev/realrandom still shows processes using it.

In Does 'urandom' share the same entropy of 'random'?, the suggestion is to use mknod /dev/random 1 9. Will this hold across restarts? Should I be using udev somehow?

  • 1
    I'd rather you didn't modify the question to suit the answers. I am not asking how to increase entropy.
    – Brian Henk
    Commented Jul 13, 2011 at 18:06

6 Answers 6


All you need to do is to create something like /etc/udev/rules.d/70-disable-random-entropy-estimation.rules with the following contents:

# /etc/udev/rules.d/70-disable-random-entropy-estimation.rules
# Disables /dev/random entropy estimation (it's mostly snake oil anyway).
# udevd will warn that the kernel-provided name 'random' and NAME= 'eerandom'
# disagree.  You can ignore this warning.

# Use /dev/eerandom instead of /dev/random for the entropy-estimating RNG.
KERNEL=="random", NAME="eerandom"

# Remove any existing /dev/random, then create symlink /dev/random pointing to
# /dev/urandom
KERNEL=="urandom", PROGRAM+="/bin/rm -f /dev/random", SYMLINK+="random"
  • 2
    +1 for actually answering the flipping question. Commented Mar 14, 2014 at 15:55
  • 1
    The first part doesn't seem to work in ubuntu 16.04, got error: systemd-udevd[818]: NAME="eerandom" ignored, kernel device nodes can not be renamed; please fix it in /etc/udev/rules.d/70-disable-random-entropy-estimation.rules:8
    – sayap
    Commented Sep 9, 2016 at 21:34

You should consider adding more entropy rather than compromising your system.

  • I have neither physical access to these systems to add hardware to increase entropy nor permanent shell access to apply kernel patches when it is updated. Are there other options to legitimately increase entropy?
    – Brian Henk
    Commented Jul 12, 2011 at 21:12
  • 2
    None of those entropy daemons are kernel patches. Commented Jul 12, 2011 at 21:15
  • How is something like timer entropy daemon better for randomness than whatever urandom uses? I don't have a sound card or video device attached, so the other two listed there will not help.
    – Brian Henk
    Commented Jul 12, 2011 at 21:34
  • 1
    urandom uses a mathematical formula to generate the next random value whenever real entropy isn't available. This mathematical formula, although seemingly random, is deterministic. Even a small bit of actual entropy is better than nothing. Commented Jul 12, 2011 at 21:40
  • 3
    Use of /dev/urandom is perfectly fine. Blocking /dev/random was a bad idea. Here's a detailed explanation: 2uo.de/myths-about-urandom - also, adding time to the entropy pool is probably way worse than the heading algorithm used by urandom
    – pilif
    Commented Sep 1, 2015 at 8:39

I've used egd to solve this problem. I'm betting you're using this with gpg. I needed to compile gpg from source to get it to work with egd, but once I did it worked very well.

Another suggestion: Sign up for an account here and download a gob of random numbers. I think you can add entropy with a simple cat file_with_random_numbers > /dev/random. There is also a utility on that site called qrand (needs to be compiled IIRC) that will download from the service and seed your /dev/random for you.

  • Unfortunately, this is a proprietary program that is reading directly from the device, so I don't think EGD would work.
    – Brian Henk
    Commented Jul 12, 2011 at 21:17
  • 1
    @ultra it's not really a good idea to get entropy from an unknown source like that. One of the key aspects you are after in the local entropy is that it is also unique. Getting it from an unknown source over a network means it may be logged, intercepted, or copied by someone else thus negating its value.
    – Keith
    Commented Jul 13, 2011 at 3:33
  • Not for super high security needs, of course not. It certainly isn't best practice. However, another secure source of random numbers could be gathered elsewhere and securely uploaded to feed the entropy. Record 10 minutes of TV static off of an analog TV or VCR, upload the resultant .wav file to server (securely) and feed it to /dev/random.
    – LawrenceC
    Commented Jul 13, 2011 at 4:50

You can set up a symlink

ln -s /dev/urandom /dev/random

Before doing so, it can be wise to mv the original random to somewhere else if you will need it again:

mv /dev/random /dev/chaos

After a restart, the changes will be gone, but you can set up udev rules to make it a permanent thing. See https://n0tablog.wordpress.com/2007/11/24/running-out-of-entropy-in-debian-etch/


Later versions of udev can't rename kernel device nodes, see https://unix.stackexchange.com/a/120272. As a workaround you can use this rule (filename could be /etc/udev/rules.d/70-random-is-urandom.rules):

KERNEL=="random", RUN+="/bin/ln -sf /dev/urandom /dev/random"

It is probably safer to use KERNEL==random than KERNEL=urandom as this version is free from any race conditions between the creation of the random and urandom device nodes. To keep both device nodes use this:

KERNEL=="random", RUN+="/bin/mv /dev/random /dev/eerandom", RUN+="/bin/ln -s /dev/urandom /dev/random"


implementing @Kent 's idea, this should do it:

printf '#!/bin/sh\nmv /dev/random /dev/random_original\nln -s /dev/urandom /dev/random' > /etc/init.d/random_noblock.sh
chmod +x /etc/init.d/random_noblock.sh
update-rc.d random_noblock.sh defaults 100

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .