You could change it to /dev/urandom if you feel that using /dev/random is affecting the JVM's startup time. But keep in mind that /dev/random is more secure that /dev/urandom and since this only affects JVM startup time then it might not be worth to change it.
It is a myth that /dev/urandom is insecure, /dev/urandom is cryptographically secure. The difference between /dev/urandom and /dev/random has no practical impact whatsoever on the security of the cryptographic protocols used within Elasticsearch (via X-Pack) (random numbers seeded by /dev/random or /dev/urandom are generated elsewhere within Elasticsearch (e.g., for generating UUIDs) but these have no intention of being secure).
Also, I'm not sure what this has to do with startup, there are not issues here like JRuby startup (that impacts Logstash).
We have common jvm configuration, one jvm instance used by Database and other jvm instance used by Elastic Search.
We have not encountered any Issue with Elastic search due to dev/random. But oracle ojdbc jar performance was not good with dev/random, as we were experiencing , Slow JDBC Connections.
So we modified this to use dev/urandom and we could see good performance on jdbc side.
I raised this query to know If dev/urandom is okay for Elastic Search.
From your comment, its okay. So this gives answer to me. Thank You.
It would be best to not run Elasticsearch and a database application on the same server, they will contend for the same resources. Also, I want to point out that you can change the source with the Java option -Djava.security.egd=file:/dev/urandom which will apply to a single JVM without having to change the security policy for the whole system.
Thank you for your Input, We are planning for separate jvm in future. Right now will go for -Djava.security.egd. I also agree we should not change standard jvm security policy.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.