18

I have the problem that Tomcat 7 is terribly slow on startup. I found this in the log file:

INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [12,367] milliseconds.

Security is important, sure, but not on my development machine. I could perfectly live with a standard fast random number generator. So I don't need this ridiculously slow SecureRandom implementation.

Question is: How can I disable it? Is searched for a solution but only found some deprecated info about a randomClass attribute which can be set to java.util.Random. I also found out that this attribute seems to be named secureRandomClass now in Tomcat 7. I tried to set it to java.util.Random but this fails because Tomcat 7 casts the object to java.util.SecureRandom (And it's also documented that the specified class must extend java.util.SecureRandom, so it's no longer possible to use java.util.Random instead.)

So how can I get rid of this terribly slow random number generator startup so my development tomcat starts/restarts as fast as possible?

kayahr
  • 18,296
  • 27
  • 93
  • 139
  • 1
    possible duplicate of [How to solve performance problem with Java SecureRandom?](http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom) – Sean Owen Sep 26 '11 at 12:13
  • 1
    @SeanOwen Not really, since that question talks about `SecureRandom` itself, not how to configure Tomcat to use a different one. [This one](http://stackoverflow.com/questions/3511205/how-to-speedup-tomcat-ssl-init) might be, though. – Dave Newton Sep 26 '11 at 12:17
  • @Dave Newton: Unfortunately this solution doesn't work for me. I'm using Linux, securerandom.source already points to /dev/urandom (Default setting) and I don't use APR so it isn't a openssl problem. – kayahr Sep 26 '11 at 12:26
  • Is 12 seconds really 'terribly slow'? Is 12 seconds such a problem that you can afford to spend all this time investigating it? – user207421 Sep 26 '11 at 12:28
  • Crap. How about [this](http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html), specifically the `randomClass` attribute? – Dave Newton Sep 26 '11 at 12:31
  • @EJP Depends on how often you start the server. And come on, you've never shaved a yak? – Dave Newton Sep 26 '11 at 12:32
  • @kayahr Can't you provide a `secureRandomClass` that extends it, but does something different on init? You should be able to write anything in it, no? – Dave Newton Sep 26 '11 at 12:43
  • @EJP: During Development I restart Tomcat pretty often. And it's not always 12 seconds. My top delay up to now is 40 seconds. Really annoying. – kayahr Sep 26 '11 at 14:21
  • @kayahr 'annoying' isn't the same thing as 'terribly slow'. Is 40 seconds really 'terribly slow'? Compared to the time you are putting into this non-productive exercise? – user207421 Sep 26 '11 at 20:41
  • 2
    @EJP seriously 12 seconds is a long time and 40 seconds is ridiculous and would drive me crazy. Do you ever restart your app? I use JRebel my secure random only takes 4 seconds but if I had to wait 40 seconds because of secure random on every code change that would piss me off. If restart time wasn't so critical then why do companies like JRebel make money? – Adam Gent Sep 15 '13 at 20:20
  • @EJP Not that it's for you or me to decide, if OP says it is, then it is. But I happen to agree with OP: 12 seconds is more than enough for my brain to switch off and completely break the flow. And a 40 second wait will definitely make me do something useful in the meantime and forget about what I was doing completely. – biziclop Sep 09 '14 at 09:21
  • If you're using embedded Tomcat, you might want to switch to Undertow, which totally removes this issue: https://stackoverflow.com/a/53571085/3369952 – Julius Delfino Dec 01 '18 at 13:21

6 Answers6

13

According to TomCat Wiki you can use non blocking entropy source:

"There is a way to configure JRE to use a non-blocking entropy source by setting the following system property: -Djava.security.egd=file:/dev/./urandom"

levsa
  • 860
  • 9
  • 16
  • This does not work for me: it still tries to get entropy from /dev/random, as kayahr's trick to link /dev/urandom to /dev/random really sped up the startup. – P.Péter Sep 22 '14 at 12:50
6

You might need to install Haveged on your server.

Tomcat is using SecureRandom to generate secure id on startup, and SecureRandom is using /dev/random or /dev/urandom to generate random number.

In some headless linux environment, /dev/random entropy pools might produce low quality of randomness and respond very slow on generating random number.

There is good article on explaining how Haveged can solve this problem.

how-to-setup-additional-entropy-for-cloud-servers-using-haveged

wLSbj
  • 61
  • 1
  • 1
2

just find securerandom.source=... from $JAVA_PATH/jre/lib/security/java.security file and change it as securerandom.source=file:/dev/./urandom

https://stackoverflow.com/a/26432537/450586

Community
  • 1
  • 1
yuceel
  • 1,922
  • 2
  • 18
  • 27
  • 1
    This reduces security. Follow this instead: https://stackoverflow.com/a/39031072/5320122 – Amit Sep 22 '17 at 10:02
2

You probably need to patch Tomcat.

Though as a hack, you could always try extending java.util.SecureRandom with something that wraps a standard java.util.Random instance....... this would get past the cast problem at least.

One other thought.... could the slowdown be due to an exhausted entropy pool? You might want to try getting more entropy into the pool, this might make it go really fast.

mikera
  • 101,777
  • 23
  • 241
  • 402
  • I hoped for a solution which tells me "put this into the configuration and it rocks". But yes, if nothing like that will pop up I have to try to write my own SecureRandom implementation. Entropy pool: Well, don't know really what this is. How can I add "more entropy"? Does it help opening the windows and let some fresh air in? Seriously, I installed a kernel module called "frandom" which generates random numbers 50 times faster (according to the doc) and pointed `securerandom.source` to this device file. Doesn't help... – kayahr Sep 26 '11 at 14:23
  • you could try /dev/erandom from the same frandom package which apparently uses no entropy at all. entropy is basically a measure of how much "pure randomness" the system has accumulated - /dev/random will block if if hasn't got enough...... so you either need to use a non-entropy-consuming RNG or create more entropy. This may or not be your particular problem though. – mikera Sep 27 '11 at 02:24
  • I also tried erandom. Doesn't help. I have the strange feeling it ignores this random source setting and always uses the blocking /dev/random. When I temporarily link /dev/random to /dev/urandom then it's fast as hell. But that's not a permanent solution. – kayahr Sep 27 '11 at 09:20
  • interesting... at least you have proved it is an entropy problem! a possible solution then is to add "fake" enropy in large quantities. I think there is an ioctl to do this but can't remember the details.... – mikera Sep 28 '11 at 04:55
  • I found two useful daemons: randomsound and haveged. The first one adds entropy gathered through sound devices and the second one maintains a pre-filled pool of random data to increase the speed of /dev/random (When I understood this correctly). I installed both and /dev/random is pretty fast now and the Tomcat delay is gone. Thanks for pointing me in the right direction! But it is still strange that I never experienced this problem before and none of my colleagues have the same problem. – kayahr Sep 30 '11 at 12:52
  • Another interesting fact: When I cat /dev/random and move around the mouse pointer by using my USB mouse then this doesn't speed up the number generation process. But using the touchpad of my notebook instead does. I checked this on a different machine and there the USB mouse also influenced the entropy pool. Strange. Differences: I use Kubuntu, the other machine uses Ubuntu. I wonder if KDE is responsible for this. Sounds strange because I thought the X-Server is responsible for handling input devices. Well, too bad, I don't have the time to investigate this in more detail. – kayahr Sep 30 '11 at 14:00
  • This probably is an incredibly stupid question but what's wrong with `/dev/urandom`? – biziclop Sep 09 '14 at 09:15
1

Old problem, but still around... In my case with an embedded Tomcat.

The -Djava.security.egd=file:/dev/./urandom solution did not work for me. So I googled until understanding the issue, but after a few tests with lsof it was apparent that the workaround doesn't work anymore. A quick look at the code confirmed that the current implementation ignores this system property.

The problem is Tomcat blocking on /dev/random, so I looked for ways to add entropy to the system and found this answer which worked great! In Debian as root:

apt-get install rng-tools
rngd -r /dev/urandom     # Run once during system start up

It may not be as super-duper-secure, but in my opinion is more that enough for session id generation.

By the way, I ended up using Jetty. Much quicker if you don't need all the features of Tomcat.

drop table
  • 27
  • 1
0

If your hardware supports it try using Java RdRand Utility available at: http://code.google.com/p/lizalab-rdrand-util/

Its based on Intel's RDRAND instruction and is about 10 times faster than SecureRandom and no bandwidth issues for large volume implementation.

Full disclosure, I'm the author of the utility.

user2781824
  • 21
  • 1