I recently had an issue with a Tomcat server taking very long to restart. It was bizarre because when the system was starting, the Tomcat server was taking about 20-30 seconds to start, but a subsequent Tomcat restart was taking 20-30 minutes.
The logs indicated that the following step was taking a lot of time:
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took  milliseconds.
This lead to the Tomcat page with advice on faster startup. The problem was – Tomcat was using
/dev/random as source of randomness, and when the entropy pool was exhausted, this device was blocking.
This explained why the problem was not manifesting right after system restart: because of the associated ‘noise’, there was a lot of entropy. But after the system was stable, the entropy pool was depleted.
The solution to this is to tell Tomcat to use the non-blocking
/dev/urandom device instead of
When read, the
/dev/randomdevice will only return random bytes within the estimated number of bits of noise in the entropy pool.
A counterpart is
/dev/urandom(“unlimited”) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from
So, to make Tomcat use
/dev/urandom you have 2 options:
1. As indicated in the Tomcat slow startup troubleshooting guide: Configure JRE to use a non-blocking entropy source by setting the following system property:
2. Change the
$JAVA_HOME/jre/lib/security/java.security settings file: