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 [135172] 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 /dev/random
:
When read, the
/dev/random
device 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/dev/random
.
wikipedia
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: Djava.security.egd=file:/dev/./urandom
2. Change the $JAVA_HOME/jre/lib/security/java.security
settings file:
securerandom.source=file:/dev/urandom
instead of
securerandom.source=file:/dev/random
More about entropy
- Likes (0)
- Comments (1)
-
Share