上海网站建设服务,临沂网站排名,手机怎么玩wordpress,网站后台建设招聘作者#xff1a;卜比
本文是《容器中的 Java》系列文章之 4/n #xff0c;欢迎关注后续连载 #x1f603; 。 系列1#xff1a;JVM 如何获取当前容器的资源限制#xff1f; 系列2#xff1a;Java Agent 踩坑之 appendToSystemClassLoaderSearch 问题 系列3#xff1a;让…作者卜比
本文是《容器中的 Java》系列文章之 4/n 欢迎关注后续连载 。 系列1JVM 如何获取当前容器的资源限制 系列2Java Agent 踩坑之 appendToSystemClassLoaderSearch 问题 系列3让 Java Agent 在 Dragonwell 上更好用 最近在容器环境中发现在 Java 进程是 1 号进程的情况下无法使用 arthas。
提示 AttachNotSupportedException: Unable to get pid of LinuxThreads manager thread。具体操作和报错如下
# java -jar arthas-boot.jar
[INFO] arthas-boot version: 3.5.6
[INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER.
* [1]: 1 com.alibabacloud.mse.demo.ZuulApplication
1
[INFO] arthas home: /home/admin/.opt/ArmsAgent/arthas
[INFO] Try to attach process 1
[ERROR] Start arthas failed, exception stack trace:
com.sun.tools.attach.AttachNotSupportedException: Unable to get pid of LinuxThreads manager threadat sun.tools.attach.LinuxVirtualMachine.init(LinuxVirtualMachine.java:86)at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:78)at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:250)at com.taobao.arthas.core.Arthas.attachAgent(Arthas.java:117)at com.taobao.arthas.core.Arthas.init(Arthas.java:27)at com.taobao.arthas.core.Arthas.main(Arthas.java:166)
[INFO] Attach process 1 success.之前也遇到过总是调整了下镜像让 Java 进程不是 1 号进程就可以了。但这个不是长久之计还是要抽时间看下这个问题。
复现问题
我们创建如下项目来复现这个问题
public class Main {public static void main(String args[]) throws Exception {while (true) {System.out.println(hello!);Thread.sleep(30 * 1000);}}
}FROM openjdk:8u212-jdk-alpine
COPY ./ /app
WORKDIR /app/src/main/java/
RUN javac Main.java
CMD [java, Main]然后正常启动应用并尝试用 arthas或者 jstack
$ # 构建镜像
$ docker build . -t example-attach
$ # 启动容器
$ docker run --name example-attach --rm example-attach$ # 在另一个终端进入容器执行jstack
$ docker exec -it example-attach sh
/app/src/main/java # jstack 1
1: Unable to get pid of LinuxThreads manager thread成功复现问题接下来开始分析。
正常的 attach 流程是什么样子的
如下是在排查问题中梳理出来的 jvm Attach 流程
查找 /tmp/.java_pid${pid} 这个 unix socket如果存在则检查权限然后建立连接。如果不存在则先创建 /proc/pid/cwd/.attachpid{pid}/cwd/.attach_pidpid/cwd/.attachpid{pid}开始通知 jvm 线程。首先判断是不是 LinuxThread如果是 LinuxThread则找到 LinuxThreadsManager然后给其所有子进程发送 SIGQUIT.如果不是 LinuxThread则直接给目标进程发送 SIGQUIT。目标进程收到信号后创建 Attach Listener监听 /tmp/.java_pid${pid}。开始正常的 socket 通信根据通信的具体内容可以是 dumpThreadjstack也可以是加载 JavaAgent比如上面提到的 arthas。
**Java Attach 机制之 Native 篇 [ 1] **也是一个不错的 attach API 解析。
为什么对1号进程 attach 会报错
首先/tmp/.java_pid${pid} 当时是肯定不存在的如果存在就是直接通信加载 Arthas 了。也可以通过查看文件来确认这一点。
其次.attach_pid${pid} 文件也是能够创建成功的
我们也可以通过 strace 输出来确认
open(“/proc/424/cwd/.attach_pid424”, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666 unfinished …。
最有可能的原因就是线程判断、发送信号这一步了我们以 jstack 为例查找为什么 attach 会失败。
本来类似上一次的查找过程想着通过调试符号来查但是在 alpine 上的调试符号无法显示源码内容编译环境又很麻烦。所以还是优先用 strace 来查值得注意的是 jstack 的逻辑中有 fork所以记得使用 strace -f jstack 1 来查。
查了下 strace 的输出没有 kill 请求。看来问题是处在线程模型判定的。
刚刚提到 jvm 会判断是不是 LinuxThread那么什么是 LinuxThread 呢首先看下判断的源码 通俗的讲Linux 内核刚开始是不支持“线程”的LinuxThread 机制就是通过 fork 机制共享内存空间的方式来实现线程。但 LinuxThread 在内核看来就是一些独立的父子进程在信号处理、同步原语上有很多缺陷要通过 manager thread 来处理这些逻辑。后来 Red Hat 发起 NPTL内核开始支持线程能力也能够通过更加标准的方式来处理信号、同步等逻辑。
可以用 getconf GNU_LIBPTHREAD_VERSION 来查看是哪种线程模型比如我的机器上输出是 NPTL 2.34。
当然如上面代码所写。可以用 confstr(_CS_GNU_LIBPTHREAD_VERSION,) 来获取当前的线程模型**详情参考手册 [ 2] **。
如果 confstr(_CS_GNU_LIBPTHREAD_VERSION,) 返回 0则表示是 glibc 旧版本认为是 LinuxThread先找到 manager thread通过查找父进程然后给各个子进程发送 SIGQUIT 信号这个过程需要遍历系统内所有进程。如果 confstr(_CS_GNU_LIBPTHREAD_VERSION,) 结果包含 NPTL则认为不是 LinuxThread按照 NPTL 来处理直接发送 SIGQUIT。
但很可惜的是LinuxThread/confstr(_CS_GNU_LIBPTHREAD_VERSION,) 不是 POSIX 标准所以 Alpine 自带的 musl 对这个调用返回 0。
按照上面逻辑jvm 会认为是 LinuxThread尝试找到父进程如果 pid 是 1 的话自然找不到父进程所以报错 Unable to get pid of LinuxThreads manager thread导致文章最开始说的 arthas 无法使用。
关于两种线程模型的详细比较可以参考 **Linux 线程模型比较LinuxThreads 和 NPTL [3 ] **。
为什么非1号进程就能 attach
模拟了下先手动进入 shell这时 sh 就是 1 号进程然后再手动执行 java Mainpid为 8 然后我们看下 getLinuxThreadsManager 是怎么表现的 可以看到在这种情况下jvm 认为 manager thread 是 1 号进程。此时会后执行 sendQuitToChildrenOf(mpid) 即遍历所有的子进程都发送 SIGQUIT这个逻辑其实是有点奇怪的。 **“超凡的主张需要有超凡的证据” [ 4] **。我们重新跑一遍用 strace -f 验证一下。
进程树其中绿色的是线程 jstack 发送的 kill 信号可以看到 jstack 给 1 号进程的所有子进程发送了 SIGQUIT 这个行为和刚刚分析是一致的。不过非常巧合的是大部分进程是忽略了 SIGQUIT 信号的所以在这种情况下jstack 反而是正常工作了的。
怎么解决这个问题
最快捷 workaround 注这种方式不需要调整容器参数不需要重启容器比较推荐。 既然 attach 主要卡在了发送信号上那我们就用 shell 来模拟这个流程
pid1 ;\
touch /proc/${pid}/cwd/.attach_pid${pid} \kill -SIGQUIT ${pid} \sleep 2 ls /proc/${pid}/root/tmp/.java_pid${pid}
# 接下来就可以正常 java -jar arthas-boot.jar 挂arthas了通过上面的操作后Attach Listener 已经启动并且监听了路径第二次 attach 就直接可以连接了就可以按照正常的方式使用 arthas 了。
其中有一点需要注意一定需要提前创建 .attach_pid${pid} 文件 不然 jvm 会将这个信号交给默认的 sigaction 处理对于 pid 1 来说会导致容器退出
也有人基于类似原理做了一个 **jattach [ 5] **工具可以直接在 Alpine 中通过 apk add jattach 来安装然后 jattach ${pid} properties也能起到一样的效果。
设置启动参数 注这种方式需要调整启动参数或者环境变量需要重启应用/容器可能会丢失业务现场。 Jvm 支持设置 -XX:StartAttachListener这样就能在启动 Jvm 的时候自动启动 Attach Listener 线程并监听也可以正常使用 arthas。
对于容器环境下更加容易的做法是给容器添加环境变量 JAVA_TOOL_OPTIONS-XX:StartAttachListener这样不用修改启动脚本也能达到效果。
上游优先修改镜像 注这种方式需要修改镜像。 OpenJDK 8 官方没有修复这个问题所以如果直接使用 openjdk:8-jdk-alpine是避免不了这个问题的。**Docker 镜像仓库也有人讨论这个问题 [ 6] **。
OpenJDK 11 就已经解决了这个问题了见**源码 [ 7] **不再对古旧的 LinuxThread 模型做判断这样 arthas 也能工作。
不过 Alpine 官方仓库中的 OpenJDK 8 已经通过自己打 patch 的方式修复了这个问题
https://gitlab.alpinelinux.org/alpine/aports/-/issues/13032
作为比较知名的 JDK 发行版也在 eclipse-temurin:8-jdk-alpine 中修复了这个问题可以直接使用这个镜像。相关讨论见
https://github.com/adoptium/jdk8u/pull/8
总结
在 arthas 的 issue 中或者网上相关的文章中总是重复着 Java 不能作为 1 号进程。很多时候就因为如此我们没有办法挂上诊断工具导致现场丢失故障原因不能及时定位。
作为技术人员还是需要了解底层这样在排查问题、架构设计上才会有更多自由度更能够抓住问题、解决问题。
后续还会出系列文章来解决容器环境下奇奇怪怪的 jvm 问题欢迎关注
相关链接
[1] Java Attach 机制之 Native 篇
https://my.oschina.net/u/3784034/blog/5526214
[2] 详情参考手册
https://man7.org/linux/man-pages/man3/confstr.3.html
[3] Linux 线程模型比较LinuxThreads 和 NPTL
https://www.jianshu.com/p/6c507b966ad1
[4] 超凡的主张需要有超凡的证据
https://zh.wikipedia.org/zh-hans/%E8%96%A9%E6%A0%B9%E6%A8%99%E6%BA%96
[5] jattach
https://github.com/apangin/jattach
[6] Docker 镜像仓库也有人讨论这个问题
https://github.com/docker-library/openjdk/issues/76
[7] 源码
https://github.com/openjdk/jdk11u/blob/jdk-11%2B28/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#L78
