Difference between /dev/urandom and /dev/./urandom?

Yong Huang yong321 at yahoo.com
Sun Sep 2 19:45:29 UTC 2012


On RHEL 6, a very simple JDBC java program returns instantly if I pass /dev/./urandom to -Djava.security.egd (entropy gathering device). But if I pass /dev/urandom to it, or omit this option altogether, it takes a long time (unless entropy has accumulated enough in the past, which doesn't happen often on this headless server; if that happened, try a few more times).

$ time java -Djava.security.egd=file:/dev/./urandom -cp .:/u01/app/oracle/product/11.2.0/db/jdbc/lib/ojdbc6.jar:/u01/app/oracle/product/11.2.0/db/jdk/jre/lib TestClient  <-- ojdbc5.jar behaves the same as ojdbc6
Got it.

real    0m0.848s  <-- always subsecond
user    0m1.064s
sys     0m0.083s
$ time java -Djava.security.egd=file:/dev/urandom -cp .:/u01/app/oracle/product/11.2.0/db/jdbc/lib/ojdbc6.jar:/u01/app/oracle/product/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 I have one more "directory" layer ".". 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?

(Those that need to refresh your memory on /dev/random and urandom, can read
http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty/
)




More information about the redhat-list mailing list