SpringBoot2应用在Docker中异常停止(Exited 139)并提示libawt.so错误,该如何解决?

springboot2 应用部署至 docker 容器后异常停止的排查

本文针对 SpringBoot2 应用在 docker 容器中运行时出现异常停止的问题进行分析和解答。该问题主要体现在容器日志中显示 Exited (139) 状态码,并伴随 libawt.so 相关的错误信息。

问题描述中,开发人员使用 Docker 19.03.13 版本,Docker Compose 部署两个相同的 SpringBoot 应用实例(pod1 和 pod2),均分配 9G 内存。应用使用了 hutool 图形验证码,并基于 openjdk:8-jdk-alpine 镜像构建了自定义镜像。pod2 容器运行一段时间后异常停止,pod1 容器则由于设置了 restart: always 而自动重启

容器日志显示 Java 运行时环境检测到致命错误 SIGILL (0x4),并在 libawt.so 库中出现问题。 ldd libjawt.so 命令的输出表明缺少 libawt_xawt.so 库,这导致 libjawt.so 库无法正确加载。

虽然系统内存充足,但 libawt.so 相关的错误提示强烈暗示问题并非内存不足,而是缺少必要的依赖库。 openjdk:8-jdk-alpine 镜像是一个精简版的 Java 运行时环境,默认不包含 AWT(抽象窗口工具包)相关的库,而 AWT 库是 hutool 图形验证码功能所依赖的。因此,仅仅安装 ttf-dejavu 和 fontconfig 还不够,因为这些库只是字体相关的,而 AWT 还需要更多图形相关的库文件。

建议尝试以下解决方案:

  1. 安装缺失的依赖库: 在 Dockerfile 中,除了 ttf-dejavu 和 fontconfig 之外,还需要安装 xorg-x11-utils (或者其在其他发行版中的等效包)。这将提供 AWT 运行所需的必要环境。 请注意,这会显著增加镜像大小。
  2. 更换基础镜像: 考虑使用一个包含完整 AWT 支持的基础镜像,例如一个包含图形化环境的 openjdk 镜像,而不是 openjdk:8-jdk-alpine。 这能避免复杂的依赖安装过程,并使镜像更加轻量级。
  3. 检查 hs_err_pid1.log: 提供完整的 hs_err_pid1.log 文件,该文件包含了 Java 虚拟机崩溃的详细信息,可以帮助更准确地定位问题。

通过以上步骤,可以尝试解决 SpringBoot 应用在 Docker 容器中因缺少图形化依赖而导致异常停止的问题。

© 版权声明
THE END
喜欢就支持一下吧
点赞15 分享