Linux Tomcat 启动卡住

本文介绍了一种解决Tomcat在Linux服务器上启动时卡顿的问题。通过调整JVM的随机数生成设置,将securerandom.source由/dev/random更改为/dev/urandom,有效避免了启动延迟。

第一次遇到Tomcat在Linux服务器启动卡住的情况,情况很简单,tomcat启动以后卡在INFO: Deploying web application directory ......这句话,具体会卡多久就没测试了。google、baidu都没找到解决方法。

幸亏UCloud的技术支持人员给出了解决方案。

找到jdk1.x.x_xx/jre/lib/security/java.security文件,在文件中找到securerandom.source这个设置项,将其改为:

securerandom.source=file:/dev/./urandom

这时候根据修改内容就可以查到因为此原因不仅可以造成tomcat卡住,也会造成weblogic启动缓慢,


linux或者部分unix系统提供随机数设备是/dev/random 和/dev/urandom ,两个有区别,urandom安全性没有random高,但random需要时间间隔生成随机数。jdk默认调用random。


再后来,终于在weblogic的官方文档中 Monitoring and Troubleshooting 找到了 Avoiding JVM Delays Caused By Random Number Generation 这样一个标题。摘录如下:

The library used for random number generation in Sun's JVM relies on /dev/random by default for UNIX platforms. This can potentially block the Oracle WebLogic Communication Services process because on some operating systems /dev/random waits for a certain amount of "noise" to be generated on the host machine before returning a result. Although /dev/random is more secure, Oracle recommends using /dev/urandom if the default JVM configuration delays Oracle WebLogic Communication Services startup.

To determine if your operating system exhibits this behavior, try displaying a portion of the file from a shell prompt:

head -n 1 /dev/random
Open the $JAVA_HOME/jre/lib/security/java.security file in a text editor.

Change the line:

securerandom.source=file:/dev/random
to read:

securerandom.source=file:/dev/urandom
Save your change and exit the text editor.
其中说到:可通过 head -n 1 /devrandom 查看是否你的系统会出现伪随机数提供等待。OK就这个,试了一下,果然,在服务器第一次启动后,这个可以快速提供一个值,但当再次调用时发生等待。


解决办法:


永久:oracle 说修改 $JAVA_HOME/jre/lib/security/java.security 文件,替换securerandom.source=file:/dev/random 为 securerandom.source=file:/dev/urandom。对所有使用JVM的应用生效。(这个永久的方法,这里面有个问题,就是设置时候实际应该设置为securerandom.source=file:/dev/./urandom,否则不生效)


DOMAIN临时:修改startWeblogic.sh文件,JAVA_OPTIONS="${SAVE_JAVA_OPTIONS} -Djava.security.egd=file:/dev/./urandom"


后继的SecureRandom 测试学习


编写JAVA类如下,运行测试,第一次正常,第二次等待,重启服务器后第一次又正常。启动加入参数 -Djava.security.egd=file:/dev/./urandom 正常

信息: Deploying web application directory lx01 2010-11-11 22:52:05 org.apache.catalina.startup.HostConfig deployDirectory 信息: Deploying web application directory blog 2010-11-11 22:52:06 org.apache.catalina.core.StandardContext listenerStart 严重: Error configuring application listener of class org.springframework.web.context.ContextLoaderListener java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3915) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4467) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:785) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:581) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) 2010-11-11 22:52:06 org.apache.catalina.core.StandardContext listenerStart 严重: Skipped installing application listeners due to previous error(s) 2010-11-11 22:52:06 org.apache.catalina.core.StandardContext start 严重: Error listenerStart 2010-11-11 22:52:06 org.apache.catalina.core.StandardContext start 严重: Context [/blog] startup failed due to previous errors ApplicationFilterConfig[name=EncodingFilter, filterClass=com.v512.guestbook.web.CharacterEncodingFilter]
### Tomcat 启动卡住的原因及解决方案 #### 日志差异分析 当遇到Tomcat启动过程中卡住的情况时,应当仔细对比正常启动的日志与异常情况下的日志。通常,在正常的启动流程下,Tomcat会在完成初始化之后打印特定的信息表示已经准备好接收请求[^1]。 #### 特定环境因素的影响 对于某些特定的操作系统和Java开发工具包(JDK)组合,比如Ubuntu上的Jdk8配Tomcat8环境下可能出现的启动停滞问题,可能是因为该环境中特有的兼容性或配置问题所引起的。这种情况下,建议尝试更换不同版本的JDK来观察是否有改善[^2]。 #### 配置文件中的潜在陷阱 在`context.xml`或其他相关配置文件中存在的不当设置也可能造成Tomcat启动过程中的延迟甚至完全停止响应。例如,存在指向不可达资源(如数据库、消息队列等)的连接字符串,并且这些连接被设定为必需成功建立才能继续执行后续操作,则一旦目标服务不可用即会造成阻塞等待状态。特别是像ActiveMQ这类外部依赖项,如果其地址配置错误或是网络状况不佳都可能导致此类现象发生[^4]。 #### 系统级资源获取冲突 另一个常见的原因是由于操作系统层面的因素影响到了应用程序的行为模式。特别是在Linux平台上运行时,若程序试图读取来自特殊设备节点的数据流用于安全目的——例如通过调用`SecureRandom.getInstanceStrong()`函数间接访问/dev/random作为强随机数源的话,那么在缺乏足够外界干扰输入的情况下(如同处于无人值守的数据中心内),此进程将会无限期挂起直到获得所需数量级别的熵值为止[^5]。 针对上述提到的各种可能性,下面给出一些具体的排查方向: - **检查并优化应用内部逻辑**:确保所有第三方库和服务都能正确工作;移除不必要的自动加载组件; - **调整加密算法强度参数**:降低对高强度伪随机序列的需求程度,改为采用更加快捷的方式生成密钥材料;考虑修改默认的安全策略以适应实际生产需求而非实验室标准; - **增强物理硬件设施的支持力度**:增加额外噪声源提高本地系统的不确定性水平从而加速随机数值产生的速度;安装专门设计用来补充额外熵池容量的小型装置。 ```bash # 修改/etc/security/limits.conf 文件增大最大打开文件描述符数目 * soft nofile 65535 * hard nofile 65535 ``` ```xml <!-- context.xml --> <Context> <!-- 移除或注释掉任何可疑的Resource定义 --> </Context> ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值