java重启太慢了_tomcat启动起来很慢,甚至是卡死在某一步骤的解决方案

本文介绍了在CentOS上启动Tomcat遇到的问题及解决方法。由于生成随机数导致启动缓慢,通过配置Java.security或catalina.sh文件指定使用/dev/urandom替代/dev/random,有效提升了启动速度。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们在服务器上启动tomcat的时候,偶尔会碰到tomcat启动起来特别慢,甚至是卡死在某一步的情况,下面记录了我一次在CentOS上启动tomcat,使用./bin/startup.sh命令启动后,通过命令 tail -f logs/catalina.out 查看tomcat日志

[root@localhost ~]# cd tomcat/

[root@localhost tomcat]# ./bin/startup.sh

Using CATALINA_BASE: /root/tomcat

Using CATALINA_HOME: /root/tomcat

Using CATALINA_TMPDIR: /root/tomcat/temp

Using JRE_HOME: /usr/local/java

Using CLASSPATH: /root/tomcat/bin/bootstrap.jar:/root/tomcat/bin/tomcat-juli.jar

Tomcat started.

[root@localhost tomcat]# tail -f logs/catalina.out

01-Jun-2019 18:02:38.514 信息 [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/root/tomcat/temp

01-Jun-2019 18:02:38.514 信息 [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]

01-Jun-2019 18:02:38.701 信息 [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]

01-Jun-2019 18:02:38.723 信息 [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read

01-Jun-2019 18:02:38.741 信息 [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-8009"]

01-Jun-2019 18:02:38.742 信息 [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read

01-Jun-2019 18:02:38.754 信息 [main] org.apache.catalina.startup.Catalina.load Initialization processed in 774 ms

01-Jun-2019 18:02:38.788 信息 [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]

01-Jun-2019 18:02:38.788 信息 [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/8.5.29

01-Jun-2019 18:02:38.821 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/root/tomcat/webapps/ROOT]

由上面日志可以看出,tomcat没有启动成功,但是也没有任何报错信息,但是过去了十几二十分钟之后,依然没有启动成功,始终卡死在 org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory 这一句。通过在网上搜索了半天终于解决了这个问题,在这里对这个问题做一下记录,免得以后碰到又再去搜索

这个问题的起因是tomcat启动的时候,需要通过Linux生成随机数的方式/dev/random生成随机数,但是如果生成随机数失败的话,就会一直阻塞中,这也就是tomcat启动为什么一直卡死某一行日志的原因,经过测试,可以通过配置/dev/urandom来取代/dev/random来解决,我们可以在两个地方进行配置,都可以解决这个问题,取其一即可

1. 在jdk安装目录配置

编辑$JAVA_HOME/jre/lib/security/Java.security文件,将securerandom.source=file:/dev/random 换成 securerandom.source=file:/dev/urandom 即可

2. 在tomcat配置文件catalina.sh中修改

tomcat的catalina.sh文件位于tomcat目录下的bin目录下,通过在catalina.sh文件添加 -Djava.security.egd=file:/dev/urandom,如下所示

2bbcf7a613a5

3. 以上两种解决方式,只需要配置一种即可,在jdk目录中进行配置,可以一劳永逸,不需要每个tomcat中进行配置,但是一般情况下我们对生产环境下的jdk没有操作权限,这时候可以使用在tomcat中配置来进行解决

配置完之后,再次启动tomcat,可以发现tomcat很快就启动成功了

[root@localhost tomcat]# tail -f logs/catalina.out

01-Jun-2019 18:27:46.100 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/root/tomcat/webapps/docs] has finished in [27] ms

01-Jun-2019 18:27:46.100 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/root/tomcat/webapps/examples]

01-Jun-2019 18:27:46.406 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/root/tomcat/webapps/examples] has finished in [306] ms

01-Jun-2019 18:27:46.409 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/root/tomcat/webapps/host-manager]

01-Jun-2019 18:27:46.436 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/root/tomcat/webapps/host-manager] has finished in [28] ms

01-Jun-2019 18:27:46.450 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/root/tomcat/webapps/manager]

01-Jun-2019 18:27:46.477 信息 [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/root/tomcat/webapps/manager] has finished in [27] ms

01-Jun-2019 18:27:46.494 信息 [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]

01-Jun-2019 18:27:46.516 信息 [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"]

01-Jun-2019 18:27:46.521 信息 [main] org.apache.catalina.startup.Catalina.start Server startup in 924 ms

<think>嗯,用户遇到了“starting switch root”卡死的问题,我需要帮他们分析可能的原因和解决方法。首先,我得回忆下Linux系统启动流程,特别是关于switch root的阶段。这个阶段通常发生在initramfs切换到真实根文件系统的时候,所以问题可能出在根文件系统的挂载上。 可能的原因有很多,我需要逐梳理。首先想到的是文件系统损坏,尤其是根文件系统。如果文件系统有错误,可能导致无法挂载。用户可能需要运行fsck来检查和修复。接下来是initramfs的问题,可能缺少必要的驱动程序或模块,特别是当使用加密或者RAID时,initramfs没有正确配置的话就会失败。还有可能是硬件问题,比如硬盘故障,或者内核参数错误,比如root=参数指定了错误的设备。 用户可能需要进入恢复模式或者使用Live CD/USB来检查系统。这时候,我应该建议他们尝试在启动时修改内核参数,添加init=/bin/bash或者单用户模式,看看能否进入shell。如果可以,就可以手动执行fsck或者检查/etc/fstab中的配置是否正确。 另外,引导加载程序配置错误也可能导致这个问题,比如GRUB中的root设备指向错误的位置。用户需要检查/boot/grub/grub.cfg中的配置是否正确,或者重新生成initramfs。对于不同的发行版,生成initramfs的命令可能不同,比如update-initramfs或dracut,需要提醒用户根据他们的系统使用正确的命令。 还有可能的内核不兼容或损坏,尤其是最近升级过内核的话,可能需要回滚到旧版本。硬件兼容性问题也不能忽视,特别是新安装的硬件或外设,可能需要移除后测试。 总结步骤,用户需要先尝试进入恢复模式,检查文件系统,验证initramfs和内核参数,修复GRUB配置,重建initramfs,检查硬件问题。如果这些都试过还不行,可能需要更深入的排查或者重装系统。 需要注意的是,用户的技术水平可能参差不齐,有些步骤可能需要详细说明,比如如何进入恢复模式,如何运行fsck命令。同时要提醒他们操作前备份重要数据,避免数据丢失。可能还需要解释些术语,比如initramfs、GRUB等,确保他们理解每个步骤的目的。</think>关于Linux系统启动时出现"starting switch root卡死"的问题,以下是逐步分析及解决方案: **1. 理解问题阶段** $$ \text{启动阶段} \rightarrow \text{内核加载} \rightarrow \text{initramfs} \rightarrow \text{switch\_root} \rightarrow \text{真实根文件系统挂载} $$ 此错误发生在initramfs向真实根文件系统切换时,属于Linux启动流程的后期阶段。 **2. 常见原因排查** *(1)文件系统损坏* - 执行硬盘检查: ```bash fsck -y /dev/sdX # 替换为实际根分区设备名 ``` - 修复后需重新生成initramfs: ```bash update-initramfs -u # Debian/Ubuntu dracut -f # RHEL/CentOS ``` *(2)Initramfs配置问题* - 检查是否缺少关键驱动: ```bash lsinitramfs /boot/initrd.img-$(uname -r) | grep drivers ``` - 手动添加驱动后重建: ```bash echo "dm_mod" >> /etc/initramfs-tools/modules # 示例添加LVM驱动 update-initramfs -u ``` *(3)GRUB配置错误* - 验证根设备参数: ```bash grep 'root=' /boot/grub/grub.cfg ``` - 临时修改启动参数(启动时按`e`编辑): ``` linux /vmlinuz root=/dev/sda1 # 确保设备路径正确 ``` *(4)硬件兼容性问题* - 检查内核日志: ```bash dmesg | grep -i error ``` - 测试硬盘健康状态: ```bash smartctl -a /dev/sda ``` **3. 高级修复流程** *(1) 使用Live CD/USB救援* ```bash mount /dev/sda1 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc chroot /mnt ``` *(2) 重建完整启动环境* ```bash grub-install /dev/sda update-grub # Debian系 grub2-mkconfig -o /boot/grub2/grub.cfg # RHEL系 ``` **4. 特殊案例处理** - 加密分区:确保`cryptsetup`包含在initramfs中 - Btrfs文件系统:检查子卷挂载参数 - 多硬盘环境:验证UUID是否冲突 **5. 日志分析要点** - 查看启动失败时的完整日志: ```bash journalctl -b -1 --priority=err # 前次启动日志 ``` - 关键排查字段: $$ \begin{cases} \text{Block layer errors} \\ \text{SCSI/SATA timeout} \\ \text{Missing mount points} \\ \text{Driver load failures} \end{cases} $$ **建议操作顺序**: 1. 检查硬盘物理连接 2. 验证文件系统完整性 3. 重建initramfs 4. 更新GRUB配置 5. 检查内核升级历史 6. 测试备用内核启动 若所有方法无效,可能需要考虑: - 备份数据后重装系统 - 更换存储硬件测试 - 提交详细日志到发行版社区 请务必在操作前备份重要数据,对关键操作建议先在虚拟机环境测试。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值