Problem phenomenon
- Start tomcat and check the log and find that it is stuck when starting to webapps/ROOT
Apr 09, 2021 4:27:12 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Apr 09, 2021 4:27:12 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 766 ms
Apr 09, 2021 4:27:12 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Apr 09, 2021 4:27:12 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.91
Apr 09, 2021 4:27:12 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory /root/transform/tomcat-transform/webapps/ROOT
Solution: Solve in the JVM environment
Open the file $JAVA_PATH/jre/lib/security/java.security and find the following
securerandom.source=file:/dev/random
Replace with
securerandom.source=file:/dev/./urandom
Talk about the difference between this random and urandom:
When tomcat starts, it will instantiate the SecureRandom object. The instantiated object uses the org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom class to generate an instance of the secure random class SecureRandom as the session ID. Tomcat uses the SHA1PRNG algorithm, which is a pseudo-random number generator based on the SHA-1 algorithm with strong confidentiality. In SHA1PRNG, there is a seed generator, which performs various operations according to the configuration.
Random numbers in Linux can be generated from two special files, one is /dev/urandom and the other is /dev/random. Their principle of generating random numbers is to use the entropy pool of the current system to calculate a fixed number of random bits, and then return these bits as a byte stream. Entropy pool is the environmental noise of the current system. Entropy refers to the degree of confusion of a system. System noise can be evaluated by many parameters, such as memory usage, file usage, and the number of different types of processes. If the current environmental noise does not change drastically or the current environmental noise is small, such as when it is just turned on, and a large number of random bits are currently needed, the random effect of the random number generated at this time is not very good.
This is why there are two different files /dev/urandom and /dev/random. The latter will block the program when it cannot generate a new random number, while the former will not (ublock). Of course, the effect of the random number generated is Not so good, this is not a good choice for applications such as encryption and decryption. /dev/random will block the current program and will not return until new random bytes are generated according to the entropy pool, so using /dev/random is slower than using /dev/urandom to generate a large number of random numbers.
SecureRandom generateSeed uses /dev/random to generate seeds. But /dev/random is a blocking number generator. If it does not have enough random data to provide, it will wait forever, which forces the JVM to wait. Keyboard and mouse input and disk activity can generate the required randomness or entropy. But the lack of such activity on a server may cause problems.
At present, both tomcat7 and tomcat8 use this method to instantiate SecureRandom objects.