RE: Difference between /dev/urandom and /dev/./urandom (Was: swingbench connection issue)

  • From: Yong Huang <yong321@xxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx, Vasu Balla <appsdba@xxxxxxxxx>
  • Date: Wed, 14 Nov 2012 14:16:02 -0800 (PST)

Thank you, Vasu. That explains it!

It's amazing a bug was submitted in 2004 but updated and resolved in 2012.

Yong Huang

--- On Wed, 11/14/12, Vasu Balla <appsdba@xxxxxxxxx> wrote:

It's a bug in Java.;jsessionid=ff625daf459fdffffffffcd54f1c775299e0?bug_id=6202721

Java picks up /dev/random even though /dev/urandom is passed in command
line. The workaround around is to trick java to use /dev/urandom, by using
/dev/./urandom. Basically it's the same device, (.) dot means current

Most Linux serves running on VMWARE or some other virtual server have
problem with slow /dev/random devices

Renaming random device and creating softlink is a good workaround, unless
you are not a Federal Regulated Environment. Data from urandom is not as
random as /dev/random device.


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Yong Huang
Sent: Wednesday, November 14, 2012 12:19 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Difference between /dev/urandom and /dev/./urandom (Was: swingbench
connection issue)

> This seems to have solved it
> *rm /dev/random*
> *ln -s /dev/urandom /dev/random
> *strange that the problem arises with one database on the box but not
> another on the same box

I have another puzzle related to /dev/(u)random. I posted somewhere else
without an answer.

On RHEL 6, a very simple JDBC java program returns instantly if I pass
/dev/./urandom to (entropy gathering device). But if I
pass /dev/urandom to it, or omit this option altogether (I assume it uses
/dev/random), it takes a long time (unless entropy happens to have
accumulated enough in the past, which doesn't happen often on this headless

$ time java -cp
uct/11.2.0/db/jdk/jre/lib TestClient  <-- ojdbc5.jar behaves the same as
ojdbc6 Got it.  <-- this is just the output of TestClient

real    0m0.848s  <-- always subsecond
user    0m1.064s
sys     0m0.083s
$ time java -cp
uct/11.2.0/db/jdk/jre/lib TestClient Got it.

real    0m7.999s  <-- anywhere from a few to tens of seconds
user    0m1.041s
sys     0m0.100s

This is very reproducible. I can't think of any difference whether there's
one more "directory" layer "." between /dev/ and urandom. Literally, it just
tells the process to go to *the current* directory which is already /dev/,
before it goes on to read urandom. Any thought?

Other related posts: