为什么在容器中 1 号进程挂不上 arthas?时间:2023-02-10 10:10:35作者:卜比 *本文是《容器中的 Java》系列文章之 4/n ,欢迎关注后续连载 :) 。* > [系列1:JVM 如何获取当前容器的资源限制?](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247548101&idx=2&sn=9b2a810941d5d61f45abbecced9667b3&chksm=fae6370acd91be1c046e6a6e9642ba3fd51156741d65b6aadbf966f7f25d426f6c71e44a7980&scene=21#wechat_redirect) > > [系列2:Java Agent 踩坑之](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247548252&idx=2&sn=fc1e31f55115315118998022b31c527d&chksm=fae63693cd91bf8501752194ae24f8e5d81394e05d9e8f10b1f5f3f6387da36e3b29a7f38a7a&scene=21#wechat_redirect) > > [appendToSystemClassLoaderSearch 问题](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247548252&idx=2&sn=fc1e31f55115315118998022b31c527d&chksm=fae63693cd91bf8501752194ae24f8e5d81394e05d9e8f10b1f5f3f6387da36e3b29a7f38a7a&scene=21#wechat_redirect) > > [系列3:让 Java Agent 在 Dragonwell 上更好用](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247548616&idx=2&sn=8c6334dd63d76b5a79b5f1bf6a510d49&chksm=fae63507cd91bc11276837fae96d54b829dc87e58501a5d62be34b31f383d9ccf0293d1e6433&scene=21#wechat_redirect) 最近在容器环境中,发现在 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 thread at sun.tools.attach.LinuxVirtualMachine.(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.(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 流程: 1. 查找 /tmp/.java_pid${pid} 这个 unix socket,如果存在则检查权限,然后建立连接。 1. 如果不存在则先创建 /proc/${pid}/cwd/.attach_pid${pid},开始通知 jvm 线程。 1. 首先判断是不是 LinuxThread如果是 LinuxThread则找到 LinuxThreadsManager,然后给其所有子进程发送 SIGQUIT. 1. 如果不是 LinuxThread,则直接给目标进程发送 SIGQUIT。 1. 目标进程收到信号后,创建 Attach Listener,监听 /tmp/.java_pid${pid}。 1. 开始正常的 socket 通信,根据通信的具体内容,可以是 dumpThread(jstack),也可以是加载 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 。 最有可能的原因就是线程判断、发送信号这一步了,我们以 jstack 为例查找为什么 attach 会失败。 本来类似[上一次的查找过程](http://mp.weixin.qq.com/s?spm=a2c6h.13046898.0.0.7f0d6ffa2XOZBc&__biz=MzUzNzYxNjAzMg==&mid=2247548252&idx=2&sn=fc1e31f55115315118998022b31c527d&chksm=fae63693cd91bf8501752194ae24f8e5d81394e05d9e8f10b1f5f3f6387da36e3b29a7f38a7a&scene=21#wechat_redirect),想着通过调试符号来查,但是在 alpine 上的调试符号无法显示源码内容,编译环境又很麻烦。所以还是优先用 strace 来查,值得注意的是, jstack 的逻辑中有 fork,所以记得使用 strace -f jstack 1 来查。 查了下 strace 的输出,没有 kill 请求。看来问题是处在线程模型判定的。 刚刚提到 jvm 会判断是不是 LinuxThread,那么什么是 LinuxThread 呢?首先看下判断的源码: ![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97660536d6eb4a99898a64a89c394870~tplv-k3u1fbpfcp-zoom-1.image "1.png") 通俗的讲,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 Main(pid为 8 ),然后我们看下 getLinuxThreadsManager 是怎么表现的: ![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2ed267963d8a4918922bdf7952bda4fb~tplv-k3u1fbpfcp-zoom-1.image "2.png") 可以看到,在这种情况下,jvm 认为 manager thread 是 1 号进程。此时会后执行 sendQuitToChildrenOf(mpid): ![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3dfed82cc60d4211ac0cfb4d928315bb~tplv-k3u1fbpfcp-zoom-1.image "3.png") ![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eb2dbea0ce754ff3af43bd6555505d0d~tplv-k3u1fbpfcp-zoom-1.image "4.png") 即遍历所有的子进程,都发送 SIGQUIT,这个逻辑其实是有点奇怪的。 **“超凡的主张,需要有超凡的证据” **[** **4]** **。我们重新跑一遍,用 strace -f 验证一下。 进程树(其中绿色的是线程): ![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/82619025adcb465fa859fa8c8d029431~tplv-k3u1fbpfcp-zoom-1.image "5.png") jstack 发送的 kill 信号,可以看到 jstack 给 1 号进程的所有子进程发送了 SIGQUIT: ![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5bae9b7b8ec745eb8327e44959e0766d~tplv-k3u1fbpfcp-zoom-1.image "6.png") 这个行为和刚刚分析是一致的。不过非常巧合的是,大部分进程是忽略了 SIGQUIT 信号的,所以在这种情况下,jstack 反而是正常工作了的。 ## 怎么解决这个问题? ### 最快捷 workaround > 注:这种方式不需要调整容器参数,不需要重启容器,比较推荐。 既然 attach 主要卡在了发送信号上,那我们就用 shell 来模拟这个流程: ``` pid=1 ;\ 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 的方式,修复了这个问题: ** 作为比较知名的 JDK 发行版,也在 eclipse-temurin:8-jdk-alpine 中修复了这个问题,可以直接使用这个镜像。相关讨论见: ** ## 总结 在 arthas 的 issue 中,或者网上相关的文章中,总是重复着 Java 不能作为 1 号进程。很多时候,就因为如此,我们没有办法挂上诊断工具,导致现场丢失,故障原因不能及时定位。 作为技术人员还是需要了解底层,这样在排查问题、架构设计上才会有更多*度,更能够抓住问题、解决问题。 后续还会出系列文章,来解决容器环境下奇奇怪怪的 jvm 问题,欢迎关注! ## 相关链接 [1] Java Attach 机制之 Native 篇 ** [2] 详情参考手册 ** [3] Linux 线程模型比较:LinuxThreads 和 NPTL ** [4] 超凡的主张,需要有超凡的证据 *[https://zh.wikipedia.org/zh-hans/%E8%96%A9%E6%A0%B9%E6%A8%99%E6%BA%96](https://zh.wikipedia.org/zh-hans/%25E8%2596%25A9%25E6%25A0%25B9%25E6%25A8%2599%25E6%25BA%2596)* [5] jattach ** [6] Docker 镜像仓库也有人讨论这个问题 ** [7] 源码 *[https://github.com/openjdk/jdk11u/blob/jdk-11%2B28/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#L78](https://github.com/openjdk/jdk11u/blob/jdk-11%252B28/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#L78)*