When setting up a server, what configuration changes do I need to make sure that all of the software uses /dev/urandom instead of /dev/random?

Some servers don't have much entropy in the entropy pool (e.g., VPSs). If a software component uses /dev/random, then it may block and cause the server to become mysteriously slower. Is there any software that comes out-of-the-box using /dev/random by default? If so, how can I configure it to force it to use /dev/urandom? It'd be nice to have a checklist of configuration settings to set, when setting up a new VPS environment.

  • Voted to close as too broad, for the reason explained in my answer on meta. Commented May 1, 2012 at 0:21
  • 2
    @Gilles I dont think it's too broad, though admittedly a list of problematic programs would never be complete - but it would be effectively complete, once it covers most of the most common programs. And, it should continue to incrementally be added to.... Though I agree about the "one per answer".
    – AviD
    Commented May 1, 2012 at 7:54
  • 3
    Should be one answer to your own question, not six. Please merge them. @Gilles lol@"Welcome" :)
    – Jeff Ferland
    Commented May 1, 2012 at 8:38

5 Answers 5


General advice

Any program written in Java


-Djava.security.egd=file:///dev/urandom switch



to the command line invocation used to start the Java process. (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.)

Alternatively, in the $JAVA_HOME/jre/lib/security/java.security configuration file, add the line


Footnote: In the above examples, you need the crazy-looking filename, e.g., the extra /./, to trick Java into accepting your filename. If you just use /dev/urandom, Java decides you didn't really mean it and replaces what you wrote with /dev/random. Craziness!


If you are starting some service in a chroot environment, don't forget to create the /dev/urandom device inside your chroot directory.

Specific software

Apache mod_ssl


SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512

in the mod_ssl configuration file. Avoid using file:/dev/random with SSLRandomSeed.

Cyrus POP3, IMAPD, and SASL

Compile Cyrus SASL (libsasl) with the configuration flag --with-devrandom=/dev/urandom.

By default, Cyrus POP3 reads from /dev/random. I couldn't find any configuration setting to change this, short of recompiling.



TLSRandFile /dev/urandom

to the slapd.conf configuration file. (This hopefully should be the default, but some guides misleadingly suggest using /dev/random, so you might want to double-check.)



tls_random_source = dev:/dev/urandom

in the main.cf configuration file, or

sudo postconf -e 'tls_random_source = dev:/dev/urandom'

from the command line.

  • Are SSLRandomSeed startup builtin and SSLRandomSeed connect builtin good enough to use?
    – kittygirl
    Commented Nov 5, 2018 at 15:30
  • @kittygirl, I would not recommend using those. As the mod_ssl documentation states, "this is not really a strong source", and it explains the source of the seed (which is not terrible but not ideal). I recommend file:/dev/urandom instead of builtin.
    – D.W.
    Commented Nov 5, 2018 at 16:48
  • I have no idea why the author of this answer hit a problem with using /dev/urandom. Maybe there was a bug in JDK or something else. Generally, the /dev/urandom and /dev/./urandom path work the same, but only the first one works correcly on Windows machines. I described how it works with OpenJDK source code examples in my answer: security.stackexchange.com/a/244954/251259
    – agabrys
    Commented Feb 17, 2021 at 8:31
  • I saw an article at redhat.com that mentioned the /dev/./urandom issue with openjdk 6 and 7.
    – Dan Pritts
    Commented Jun 4, 2021 at 17:59
  • @agabrys, this is a super old answer, and I don't know whether it's still needed any more. Maybe it was a bug in an old JDK. I don't have time to investigate but maybe someone else will. It's a little tricky to test: if indeed the JDK is still remapping that to /dev/random, it's likely that everything will appear to "work" as far as can be observed externally (because on most machines, after they've been running for a while, /dev/random won't block if you call it once), so it might take some extra doing to get a definitive answer.
    – D.W.
    Commented Jun 4, 2021 at 18:43


As root, just do this:

rm /dev/random
mknod /dev/random c 1 9

Now /dev/random will actually access the same underlying logic as /dev/urandom.

After this change, both /dev/random and /dev/urandom will draw from the non-blocking pool. The non-blocking pool will draw from the blocking pool, which the system will still fill.

  • 4
    Yes, it's safe. After this change, /dev/random becomes just another name for /dev/urandom. So nothing you previously knew about /dev/random applies any more. (Specifically, it is no longer in any way associated with the pool that /dev/urandom draws off.) Commented May 1, 2012 at 10:34
  • 13
    @Polynomial “/dev/urandom is seeded from entropy in /dev/random” is a shortcut. Actually, /dev/random and /dev/urandom are both doorways into the same driver inside Linux kernel. The entropy feed happens inside the kernel. Erasing the label on one of the doorways doesn't change what happens under the hood. Commented May 1, 2012 at 10:55
  • 1
    afaik, freebsd is using prng for both /dev/urandom and /dev/random Commented May 3, 2012 at 22:45
  • 2
    @Navin It does remove a safety against broken startup. You're still safe as long as your startup logic correctly seeds the entropy pool. If you're paranoid, you could add an extra startup script that runs after the pool is supposed to be seeded and checks to make sure that the pool actually was seeded and halts the system if it isn't. Commented Jan 7, 2016 at 18:43
  • 2
    @DavidSchwartz Fair enough. Maybe one of these days, linux will get a new /dev/srandom device which blocks until it is reseeded and never blocks again. Then I can hardlink it to /dev/random. A man can dream.
    – Navin
    Commented Jan 9, 2016 at 12:08

Great initiative by D.W. to list different software configurations (I am a die-out fan of D.W. already)

BUT - As I mentioned on my previous comment, On my VPS servers I personally still prefer to install one single component (haveged) that gets everything running smoothly.

Perhaps @DavidSchwartz's suggestion is the only one that could be even easier, but I haven't tried it.

Individually configuring each component instead of the underlying entropy pool sounds a little silly to me to be perfectly honest. When I have a problem, I try to solve the root cause and keep the DRY principle.



For PHP sessions you can use /dev/urandom as an entropy source

session.entropy_file = /dev/urandom

JAVA Application/Server

I would recommended to read the Everything about Java's SecureRandom article.


You have two options:

  1. set the java.security.egd system property to file:/dev/urandom. The easiest option is to configure it by using the JAVA_TOOL_OPTIONS environment variable:

    export JAVA_TOOL_OPTIONS = '-Djava.security.egd=file:/dev/urandom'
  2. set the securerandom.source security property in the Java Security file to file:/dev/urandom:


    It could be defined in the following locations:

    • $JAVA_HOME/jre/lib/security/java.security (all JDK versions)
    • $JAVA_HOME/conf/security (JDK 9+)

Don't use /dev/./urandom

Don't use the mentioned file:/dev/./urandom path. The sun.security.provider.SeedGenerator class supports paths as follow:

It generally means that setting /dev/./urandom works the same as setting /dev/urandom. There is only one difference - it works only on Unix machines. On Windows it throws IOException because /dev/./urandom is an invalid path. /dev/urandom works because for this path a new instance of the Windows compatible NativeSeedGenerator class is created.

The core part of the sun.security.provider.SeedGenerator class:

 * Try the URL specifying the source (e.g. file:/dev/random)
 * The URLs "file:/dev/random" or "file:/dev/urandom" are used to
 * indicate the SeedGenerator should use OS support, if available.
 * On Windows, this causes the MS CryptoAPI seeder to be used.
 * On Solaris/Linux/MacOS, this is identical to using
 * URLSeedGenerator to read from /dev/[u]random
if (egdSource.equals(SunEntries.URL_DEV_RANDOM) ||
        egdSource.equals(SunEntries.URL_DEV_URANDOM)) {
    try {
        instance = new NativeSeedGenerator(egdSource);
        if (debug != null) {
                "Using operating system seed generator" + egdSource);
    } catch (IOException e) {
        if (debug != null) {
            debug.println("Failed to use operating system seed "
                          + "generator: " + e.toString());
} else if (egdSource.length() != 0) {
    try {
        instance = new URLSeedGenerator(egdSource);
        if (debug != null) {
            debug.println("Using URL seed generator reading from "
                          + egdSource);
    } catch (IOException e) {
        if (debug != null) {
            debug.println("Failed to create seed generator with "
                          + egdSource + ": " + e.toString());

You must log in to answer this question.

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