全新的CentOS,全新的Tomcat。
启动Tomcat后,关闭Tomcat报错:
[root@aliyun bin]# ./shutdown.sh
Using CATALINA_BASE: /home/tomcat
Using CATALINA_HOME: /home/tomcat
Using CATALINA_TMPDIR: /home/tomcat/temp
Using JRE_HOME: /usr
Using CLASSPATH: /home/tomcat/bin/bootstrap.jar:/home/tomcat/bin/tomcat-juli.jar
Sep 04, 2018 5:16:30 PM org.apache.catalina.startup.Catalina stopServer
SEVERE: Could not contact localhost:8005. Tomcat may not be running.
Sep 04, 2018 5:16:30 PM org.apache.catalina.startup.Catalina stopServer
SEVERE: Catalina.stop:
java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.<init>(Socket.java:434)
at java.net.Socket.<init>(Socket.java:211)
at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:450)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:400)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:487)
报错显示shutdown端口8005都没有,tomcat没启动起来。查看日志,并没有报错。
tomcat真的没有启动起来没,事实上也确实如此,等上几分钟后再执行shutdown.sh,可以正常关闭tomcat了。
查看tomcat日志,发现SecureRandom的创建操作花费了大量时间,几百秒,所以tomcat启动很慢,而没等到tomcat启动起来就执行shutdown,就会发生前面的错误。
[root@aliyun logs]# cat catalina.out |grep Random
04-Sep-2018 16:49:02.202 INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [238,145] milliseconds.
以下是网上找到的资料:
根本原因是 SecureRandom 这个 jre 的工具类的问题。那为什么 SecureRandom generateSeed 这么慢,甚至挂在 Linux 操作系统呢?
Tomcat 7/8 都使用 org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom 类产生安全随机类 SecureRandom 的实例作为会话 ID。
Tomcat 使用 SHA1PRNG 算法是基于 SHA-1 算法实现且保密性较强的伪随机数生成器。
在 SHA1PRNG 中,有一个种子产生器,它根据配置执行各种操作。
Linux 中的随机数可以从两个特殊的文件中产生,一个是 /dev/urandom,另外一个是 /dev/random。他们产生随机数的原理是利用当前系统的熵池来计算出固定一定数量的随机比特,然后将这些比特作为字节流返回。熵池就是当前系统的环境噪音,熵指的是一个系统的混乱程度,系统噪音可以通过很多参数来评估,如内存的使用,文件的使用量,不同类型的进程数量等等。如果当前环境噪音变化的不是很剧烈或者当前环境噪音很小,比如刚开机的时候,而当前需要大量的随机比特,这时产生的随机数的随机效果就不是很好了。
这就是为什么会有 /dev/urandom 和 /dev/random 这两种不同的文件,后者在不能产生新的随机数时会阻塞程序,而前者不会(ublock),当然产生的随机数效果就不太好了,这对加密解密这样的应用来说就不是一种很好的选择。/dev/random 会阻塞当前的程序,直到根据熵池产生新的随机字节之后才返回,所以使用 /dev/random 比使用 /dev/urandom 产生大量随机数的速度要慢。
SecureRandom generateSeed 使用 /dev/random 生成种子。但是 /dev/random 是一个阻塞数字生成器,如果它没有足够的随机数据提供,它就一直等,这迫使 JVM 等待。键盘和鼠标输入以及磁盘活动可以产生所需的随机性或熵。但在一个服务器缺乏这样的活动,可能会出现问题。
有2种解决方案:
1. 在Tomcat环境中解决:
可以通过配置 JRE 使用非阻塞的 Entropy Source:
在 catalina.sh 中加入这么一行:-Djava.security.egd=file:/dev/./urandom 即可。
2. 在 JVM 环境中解决:
打开 $JAVA_PATH/jre/lib/security/java.security 这个文件,找到下面的内容:
1 |
|
替换成:
1 |
|
这里值为何要在 dev 和 random 之间加一个点呢?是因为一个 JDK 的 bug,有人反馈即使对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random,有人提供了变通的解决方法,其中一个变通的做法是对 securerandom.source 设置为 /dev/./urandom 才行。也有人评论说这个不是 bug,是有意为之。
在 JDK 7 的 java.security 文件里,配置里的是:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
但这个 /dev/urandom 也同那个 bug 报告里所说的等同于 /dev/random;要使用非阻塞的熵池,这里还是要修改为 /dev/./urandom。经测试,貌似 JDK 7 并没有同注释里的意思修复了这个问题。