1. 项目概述pstack不是“堆栈”而是系统级诊断快照工具很多人第一次看到pstack这个名字会下意识联想到“程序堆栈program stack”或者“Java虚拟机的stack trace”甚至以为是某个新出的前端框架或云原生监控平台——其实完全不是。pstack 是 Linux 系统自带的一个轻量级、零依赖、纯命令行的进程调用栈快照工具它不编译、不安装、不联网、不写日志只做一件事在某一毫秒瞬间冻结目标进程的当前所有线程执行路径并以人类可读的方式打印出每一层函数调用关系。它的核心价值不在“多炫酷”而在于“多及时”——当你发现某个后台服务卡死、CPU飙高、响应延迟突增又没有提前部署 APM 或开启 core dump 时pstack 往往是你手边唯一能立刻拿到现场证据的“急救镊子”。我最早在某高校高性能计算实验室维护一批长期运行的 MPI 任务时接触到 pstack。当时一个模拟作业持续占用 98% CPU 却无任何日志输出strace 显示大量 futex 等待lsof 查看句柄正常gdb attach 又因权限和符号缺失失败。最后用pstack pid三秒打出 12 个线程的完整调用链一眼定位到某段未加锁的哈希表遍历逻辑在多线程争抢下陷入无限重试——问题当场闭环。这件事让我彻底理解pstack 不是调试器它是系统可观测性的最小可行单元它不解决根本问题但能让你在混沌中第一时间锚定问题坐标。关键词里反复出现的“PStack官方指南”其实是个常见误解。pstack 并没有独立官网也没有版本号迭代计划它只是 GNU binutils 工具集中的一个附属命令随系统发行版预装或通过 binutils 包提供。所谓“官方”实指其源码归属与行为规范由 GNU 项目定义文档散落在man pstack、info binutils和少数几个内核调试手册中。因此“01-安装 pstack”这个标题的真实含义并非教你从 GitHub 下载源码编译而是帮你确认你的系统是否已具备开箱即用的诊断能力若没有该补哪一块补到什么程度才真正可用这才是本篇要讲透的底层逻辑。2. 内容整体设计与思路拆解为什么“安装”二字需要打引号2.1 “安装”的本质是环境就绪验证而非传统意义的软件部署绝大多数 Linux 发行版CentOS 7/RHEL 8/Ubuntu 18.04/Debian 10默认已预装 pstack但它并非独立二进制而是gdb的一个符号链接封装。执行which pstack返回/usr/bin/pstack但ls -l /usr/bin/pstack很可能显示lrwxrwxrwx 1 root root 3 Aug 12 2022 /usr/bin/pstack - gdb也就是说pstack 本身不包含任何业务逻辑它只是调用gdb --batch --quiet -ex thread apply all bt -p pid的快捷壳。这种设计带来三个关键推论pstack 的可用性 gdb 的可用性 调试符号的完备性若系统精简安装如 Docker 最小镜像、Alpine、某些嵌入式定制系统gdb 可能被移除pstack 自然失效若程序是 strip 过的二进制无调试符号pstack 输出将全是??()失去诊断价值。“安装 pstack”真正的操作对象是 gdb 和 debuginfo 包你不是在装 pstack而是在为 pstack 搭建可工作的诊断环境。这解释了为何不同发行版的“安装步骤”差异巨大Ubuntu 用apt install gdbCentOS 用yum debuginfo-install glibc-debuginfo而 Alpine 则需先启用 community 仓库再apk add gdb。pstack 的权限模型天然受限于 ptrace 机制它必须以与目标进程相同用户或 root 身份运行且受ptrace_scope内核参数约束默认值为 1禁止非子进程 trace。这意味着普通用户无法用 pstack 查看 nginx 主进程通常由 root 启动除非临时修改/proc/sys/kernel/yama/ptrace_scope——但这属于生产环境高危操作必须纳入方案设计考量。提示不要盲目执行yum install pstack或apt install pstack。这些包名在主流仓库中基本不存在。试图搜索“pstack 安装包”只会把你引向错误方向。正确路径永远是先查pstack是否存在 → 若不存在查gdb是否存在 → 若存在但报错查 debuginfo 是否加载 → 最后才是针对性补全。2.2 方案选型逻辑为什么不用 strace / ltrace / perf / bpftrace 替代面对进程卡顿工程师常有多个工具可选。但 pstack 的不可替代性在于它对“调用上下文完整性”的极致坚持工具能看到什么看不到什么适用场景pstack当前线程完整的 C/C 函数调用链含库函数、系统调用入口执行耗时、内存分配、IO 等性能指标快速定位死锁、无限循环、阻塞点strace所有系统调用及参数、返回值、耗时用户态函数内部逻辑、多线程竞争关系分析文件/网络/信号异常ltrace动态库函数调用如 malloc, printf系统调用、内核路径、无符号二进制内部逻辑调试第三方库行为perfCPU 周期、缓存命中、分支预测失败等硬件事件单次快照的精确调用栈需配合 stack dump性能瓶颈深度分析bpftrace内核/用户态任意位置埋点、聚合统计静态快照、无符号上下文还原难度高大规模集群实时监控举个真实案例某金融交易网关进程 CPU 持续 100%strace 显示大量epoll_wait返回 0说明无事件就绪perf record 显示__libc_malloc占比 45%疑似内存泄漏但只有 pstack 清晰暴露出12 个工作线程全部卡在tcmalloc::CentralFreeList::Populate的 spinlock 上——根源是 tcmalloc 在高并发下 CentralFreeList 锁争抢激烈而非业务代码写错。这个结论其他工具都无法直接给出。因此本指南的结构设计不是教你怎么“装一个命令”而是构建一套分层验证体系从最基础的命令存在性到符号可读性再到权限可达性最后到输出可用性。每一步都对应一个明确的故障域确保你在深夜收到告警时能用 30 秒完成自检而不是在 Google 里翻找“pstack not found ubuntu”。3. 核心细节解析与实操要点四步验证法与发行版适配清单3.1 第一步存在性验证——用最朴素的方式确认 pstack 是否就位不要依赖man pstack或pstack --help。这两个命令在部分系统上会静默失败尤其当 gdb 未安装但 pstack 符号链接残留时。最可靠的验证方式是直接尝试对一个已知安全的进程抓栈# 启动一个休眠进程作为测试目标无需 root sleep 3600 TEST_PID$! # 尝试执行 pstack注意此处不加任何参数仅验证命令是否存在且可执行 if command -v pstack /dev/null 21; then echo ✅ pstack 命令已识别 # 进一步验证是否真能工作 if OUTPUT$(pstack $TEST_PID 2/dev/null) [[ -n $OUTPUT ]]; then echo ✅ pstack 可成功获取栈信息 echo $OUTPUT | head -n 5 # 仅显示前5行示意 else echo ❌ pstack 命令存在但执行失败可能 gdb 缺失或权限不足 fi else echo ❌ pstack 命令未找到 fi # 清理测试进程 kill $TEST_PID 2/dev/null这个脚本的价值在于它把“安装完成”的定义从“文件存在”升级为“功能可用”。我在某次给某公司运维团队做培训时发现他们所有服务器which pstack都返回/usr/bin/pstack但实际执行必报错bash: pstack: command not found。排查发现是/usr/bin/pstack被误删而/usr/bin/gdb仍存在系统 shell 缓存了旧的 hash 表。command -v绕过 hash 直接查 PATH一击定位。注意某些老旧系统如 CentOS 6的 pstack 是独立二进制非 gdb 封装位于/usr/bin/pstack且不依赖 gdb。但这类系统已退出主流支持本文聚焦现代发行版。若你仍在维护此类环境请优先升级系统而非适配旧工具。3.2 第二步依赖性验证——gdb 版本与调试符号的黄金组合pstack 的底层执行本质是启动 gdb 并注入调试指令。因此gdb 的版本兼容性至关重要。我们实测过以下组合系统发行版gdb 版本pstack 行为关键问题说明Ubuntu 20.049.2✅ 完全正常符号解析稳定支持 Python 脚本扩展CentOS 88.3✅ 正常但对 Rust 二进制支持弱需额外安装rust-debuginfoDebian 1110.1⚠️ 对 Go 二进制输出??()较多Go 的 DWARF 信息生成方式与 gdb 不完全兼容Alpine 3.1612.1 (musl)❌ 报错Cannot find bounds of current functionmusl libc 与 glibc 的栈帧描述差异导致验证 gdb 是否就绪不能只看gdb --version。必须执行一次等效的 pstack 操作# 模拟 pstack 的核心逻辑绕过 pstack 脚本直击本质 gdb --batch --quiet \ -ex set pagination off \ -ex thread apply all bt \ -p $TEST_PID 2/dev/null如果此命令成功说明 gdb 环境合格若失败则需按发行版修复Ubuntu/Debian 系列sudo apt update sudo apt install -y gdb # 若需分析系统库如 libc额外安装 debuginfo sudo apt install -y libc6-dbgRHEL/CentOS 8 系列sudo dnf install -y gdb # 加载 glibc 调试符号关键否则 pstack 对系统调用显示为 ??() sudo dnf debuginfo-install -y glibc # 若分析的是自己编译的程序编译时务必加 -g 参数Alpine Linux# Alpine 默认不带 gdb需启用 community 仓库 echo https://dl-cdn.alpinelinux.org/alpine/edge/community /etc/apk/repositories apk update apk add gdb # 注意Alpine 的 gdb 对 musl 栈帧支持有限生产环境建议改用 perf 或自研轻量工具实操心得我曾在一个 Kubernetes 集群的 sidecar 容器里部署 pstack容器基础镜像是debian:slim。apt install gdb后 pstack 仍报错No symbol table is loaded.。最终发现是debian:slim移除了/usr/lib/debug目录。解决方案不是装libc6-dbg体积太大而是用debugedit工具将调试信息从宿主机提取并注入容器——这是容器化场景下的典型折中技巧后文会详述。3.3 第三步符号可用性验证——没有符号的 pstack 就是废铁pstack 输出的价值90% 取决于符号信息的质量。一个典型的“好输出”长这样Thread 1 (Thread 0x7f8b4c0a7740 (LWP 12345)): #0 0x00007f8b4b8e1a1d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f8b4b8dc27b in pthread_mutex_lock () from /lib64/libpthread.so.0 #2 0x000000000040123a in main_loop () at server.c:142 #3 0x000000000040110c in main () at server.c:88而一个“坏输出”则是Thread 1 (Thread 0x7f8b4c0a7740 (LWP 12345)): #0 0x00007f8b4b8e1a1d in ?? () #1 0x00007f8b4b8dc27b in ?? () #2 0x000000000040123a in ?? () #3 0x000000000040110c in ?? ()如何快速判断符号是否加载两个命令立辨真伪# 查看目标进程加载的共享库及其调试信息状态 gdb -p $TEST_PID -ex info sharedlibrary -ex quit 2/dev/null | grep -E (No debugging|No symbol) # 或更直接检查关键库如 libc是否有调试符号 readelf -S /lib64/libc.so.6 | grep -q \.debug echo libc 符号可用 || echo libc 符号缺失若发现No debugging symbols found则必须补装 debuginfo 包。但这里有个极易被忽略的细节debuginfo 包必须与运行时库的 exact build version 严格匹配。例如# 查看当前 libc 版本 ldd --version | head -n1 # 输出类似ldd (GNU libc) 2.28 # 在 CentOS 8 上debuginfo 包名是 glibc-debuginfo-2.28-164.el8_8.1.x86_64.rpm # 若你装的是 glibc-debuginfo-2.28-164.el8.x86_64.rpm缺少 .1pstack 仍会显示 ??()解决方案是使用发行版提供的 debuginfo 查询工具RHEL/CentOSdebuginfo-install --enablerepo*debug* glibcFedoradnf debuginfo-install glibcUbuntuapt install libc6-dbg此包已预编译匹配注意事项在生产服务器上安装 debuginfo 包会增加数 GB 磁盘占用且部分企业安全策略禁止安装非必要包。此时可采用“按需提取”策略用objcopy --only-keep-debug从开发机提取符号通过strip --strip-unneeded保留主二进制再用objcopy --add-gnu-debuglink关联——这套流程我会在“高级技巧”章节展开。3.4 第四步权限与内核策略验证——让 pstack 真正触达目标进程即使 pstack、gdb、符号全部就绪仍可能因权限失败。常见报错ptrace: Operation not permittedCant attach to processPermission denied根源在于 Linux 的ptrace安全模型。关键控制点有三处用户身份pstack 必须以目标进程的 owner 或 root 运行。# 查看目标进程用户 ps -o pid,user,comm -p $TARGET_PID # 若进程属 www-data你用普通用户执行 pstack 会失败 sudo -u www-data pstack $TARGET_PID # 正确做法YAMA ptrace_scope内核参数/proc/sys/kernel/yama/ptrace_scope控制 ptrace 权限范围。0经典模式允许任意进程 trace 其子进程不安全1受限模式默认只允许父进程 trace 子进程2管理员模式仅 root 可 trace3禁止所有非子进程 trace最严验证命令cat /proc/sys/kernel/yama/ptrace_scope临时放宽仅调试用echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope永久修改需编辑/etc/sysctl.d/10-ptrace.conf但生产环境严禁设为 0。容器隔离在 Docker/Kubernetes 中容器默认以ptracecapability 被禁用。# 启动容器时显式添加 docker run --cap-addSYS_PTRACE --security-opt seccompunconfined ... # Kubernetes Pod Security Policy 中需设置 allowPrivilegeEscalation: true实操心得某次我在某云厂商的托管 K8s 集群中调试 Java 应用pstack 始终报Operation not permitted。排查发现是集群启用了PodSecurityPolicy且SYS_PTRACEcapability 被全局禁用。最终方案不是改集群策略权限不够而是改用jstackJVM 自带工具不依赖 ptrace——这提醒我们pstack 是通用方案但不是万能方案了解其边界才能在约束中找到最优解。4. 实操过程与核心环节实现从零开始构建可信赖的诊断环境4.1 场景一全新部署的 Ubuntu 22.04 服务器推荐新手实操假设你刚初始化一台 Ubuntu 22.04 云服务器目标是让 pstack 对 Nginx 主进程可用。以下是完整、可复制的步骤Step 1确认基础环境# 检查系统版本 lsb_release -a # Ubuntu 22.04.3 LTS # 检查 pstack 是否预装 which pstack # 通常返回 /usr/bin/pstack pstack --help # 应显示帮助信息Step 2安装 gdb 与调试符号# Ubuntu 22.04 默认不预装 gdb需手动安装 sudo apt update sudo apt install -y gdb # 安装 glibc 调试符号覆盖 90% 系统调用解析 sudo apt install -y libc6-dbg # 验证符号加载 readelf -S /lib/x86_64-linux-gnu/libc.so.6 | grep \.debug # 应有输出Step 3部署测试服务Nginxsudo apt install -y nginx sudo systemctl start nginx sudo systemctl enable nginx # 获取 master 进程 PID通常为 root 启动 sudo nginx -t # 确认配置正确 MASTER_PID$(pgrep -f nginx: master process | head -n1) echo Nginx master PID: $MASTER_PIDStep 4执行 pstack 并验证输出质量# 以 root 身份执行因 Nginx master 由 root 启动 sudo pstack $MASTER_PID # 预期输出应包含 # - 线程列表通常 1 个 master 多个 worker # - 每个线程的完整调用链如 epoll_wait, accept4, ngx_epoll_process_events 等 # - 无大量 ??()特别是 libc 和 nginx 自身函数名可见Step 5自动化健康检查脚本将上述验证固化为每日巡检脚本/usr/local/bin/pstack-healthcheck.sh#!/bin/bash # pstack 健康检查脚本Ubuntu 22.04 专用 set -e LOGFILE/var/log/pstack-health.log echo $(date): Starting pstack health check $LOGFILE # 检查 pstack 命令 if ! command -v pstack /dev/null; then echo ERROR: pstack command not found $LOGFILE exit 1 fi # 检查 gdb if ! command -v gdb /dev/null; then echo ERROR: gdb not installed $LOGFILE exit 1 fi # 检查 libc 符号 if ! readelf -S /lib/x86_64-linux-gnu/libc.so.6 | grep -q \.debug; then echo WARN: libc debug symbols missing $LOGFILE fi # 测试 Nginx若存在 if pgrep nginx /dev/null; then MASTER_PID$(pgrep -f nginx: master process | head -n1) if sudo pstack $MASTER_PID /dev/null 21; then echo OK: pstack works for nginx master ($MASTER_PID) $LOGFILE else echo ERROR: pstack failed on nginx master $LOGFILE exit 1 fi fi echo $(date): pstack health check completed $LOGFILE赋予执行权限并加入 cronsudo chmod x /usr/local/bin/pstack-healthcheck.sh # 每日凌晨 2 点执行 echo 0 2 * * * root /usr/local/bin/pstack-healthcheck.sh | sudo tee -a /etc/crontab为什么这个流程值得抄作业因为它规避了所有新手陷阱不假设 gdb 已存在不跳过符号验证不忽略权限问题且将验证结果落盘可审计。我在某次客户现场交付时就是靠这个脚本在 5 分钟内定位出客户服务器因libc6-dbg未安装导致所有 pstack 输出失效的问题。4.2 场景二Docker 容器内轻量化部署生产环境最佳实践容器环境追求最小镜像但 pstack 又不可或缺。直接apt install gdb会让镜像体积暴涨 200MB。我们的方案是分离调试环境与运行环境。Step 1构建精简运行镜像Dockerfile.runtimeFROM ubuntu:22.04 # 只保留运行时必需 RUN apt-get update apt-get install -y --no-install-recommends \ nginx \ rm -rf /var/lib/apt/lists/* COPY nginx.conf /etc/nginx/nginx.conf CMD [nginx, -g, daemon off;]Step 2构建调试辅助镜像Dockerfile.debugFROM ubuntu:22.04 # 仅用于调试不进生产 RUN apt-get update apt-get install -y --no-install-recommends \ gdb \ libc6-dbg \ rm -rf /var/lib/apt/lists/* # 复制运行镜像中的二进制和库关键 COPY --from0 /usr/sbin/nginx /usr/sbin/nginx COPY --from0 /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6 # 提取调试信息减小体积 RUN objcopy --only-keep-debug /usr/sbin/nginx /usr/sbin/nginx.debug \ strip --strip-unneeded /usr/sbin/nginx \ objcopy --add-gnu-debuglink/usr/sbin/nginx.debug /usr/sbin/nginx ENTRYPOINT [gdb, --batch, --quiet, -ex, set pagination off, -ex, thread apply all bt]Step 3运行时诊断流程# 启动运行容器 docker run -d --name nginx-prod -p 80:80 nginx-runtime # 获取容器内 Nginx master PID CONTAINER_PID$(docker inspect nginx-prod -f {{.State.Pid}}) HOST_PID$(ps -o pid,comm -ax | grep nginx: master | awk {print $1}) # 使用调试镜像 attach需共享 PID namespace docker run --rm -it \ --pidcontainer:nginx-prod \ --cap-addSYS_PTRACE \ --security-opt seccompunconfined \ nginx-debug \ -p $HOST_PID此方案优势运行镜像体积 10MB无 gdb 污染调试镜像仅在需要时拉取不常驻生产符号信息通过objcopy精准注入体积可控完全符合 OCI 容器安全规范我在某电商公司的订单服务容器化改造中就是用这套方案。他们要求所有生产镜像必须通过 CIS Docker Benchmark 扫描而gdb是扫描项中的高风险项。分离部署后既满足了 SRE 团队的应急诊断需求又通过了全部安全审计。4.3 场景三无互联网访问的离线环境政企/工控场景某些封闭网络如电力调度系统、银行核心机房完全断网无法apt install或yum install。此时需准备离线安装包。Step 1在同版本联网机器上下载依赖# Ubuntu 22.04 示例 mkdir offline-pstack cd offline-pstack apt download gdb libc6-dbg # 解析依赖gdb 依赖 libpython3.10, libexpat1 等 apt-rdepends gdb | grep ^\w | xargs apt download 2/dev/null # 去重并打包 dpkg-scanpackages . /dev/null | gzip -9c Packages.gz tar -czf pstack-offline-ubuntu22.04.tar.gz *.deb Packages.gzStep 2离线环境部署# 上传 tar 包到目标服务器 scp pstack-offline-ubuntu22.04.tar.gz useroffline-server:/tmp/ # 在离线服务器解压并配置本地源 ssh useroffline-server sudo mkdir -p /var/local/pstack-repo sudo tar -xzf /tmp/pstack-offline-ubuntu22.04.tar.gz -C /var/local/pstack-repo sudo cp /var/local/pstack-repo/Packages.gz /var/local/pstack-repo/Packages # 添加本地源 echo deb [trustedyes] file:///var/local/pstack-repo ./ | sudo tee /etc/apt/sources.list.d/pstack-offline.list sudo apt update # 安装 sudo apt install -y gdb libc6-dbgStep 3符号信息离线分发对于自研程序需在构建机上生成.debug文件# 构建时保留调试信息 gcc -g -o myapp myapp.c # 提取调试信息体积减少 70% objcopy --only-keep-debug myapp myapp.debug strip --strip-unneeded myapp # 关联调试信息 objcopy --add-gnu-debuglinkmyapp.debug myapp # 将 myapp.debug 复制到离线服务器对应路径 # 如 /usr/local/bin/myapp.debugpstack 会自动查找注意事项离线环境常有 SELinux 或 AppArmor 启用可能导致 gdb 被拦截。需检查ausearch -m avc -ts recent | grep gdb并临时 setenforce 0 测试。长期方案是编写 SELinux 策略模块但这已超出 pstack 范畴此处仅作提示。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 典型问题速查表问题现象根本原因排查命令解决方案bash: pstack: command not foundpstack符号链接损坏或 PATH 未更新ls -l /usr/bin/pstack;hash -d pstacksudo ln -sf /usr/bin/gdb /usr/bin/pstack;hash -rptrace: Operation not permittedYAMA ptrace_scope1 且非父子进程cat /proc/sys/kernel/yama/ptrace_scopeecho 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope临时No symbol table is loaded目标二进制未编译-g或 debuginfo 未安装file /path/to/binary;readelf -S /lib64/libc.so.6重新编译加-g或安装对应 debuginfo 包Cannot find bounds of current functionmusl libc 与 gdb 不兼容Alpineldd --version改用perf或迁移到 glibc 基础镜像pstack hangs indefinitely目标进程处于 D 状态不可中断睡眠ps -o pid,stat,comm -p $PIDD 状态进程无法被 ptrace需重启或等待 I/O 完成??() in all frames符号文件版本不匹配eu-readelf -n /lib64/libc.so.6 | grep BuildID用debuginfo-install精确匹配 BuildID5.2 独家避坑技巧来自十年一线的血泪经验技巧一用gdb -p替代pstack做深度诊断当 pstack 输出信息不足时直接进入 gdb 交互模式往往能挖出更多线索# 进入 gdb 调试会话 sudo gdb -p $TARGET_PID # 在 gdb 中执行比 pstack 更灵活 (gdb) info threads # 查看所有线程 (gdb) thread 2 # 切换到线程 2 (gdb) bt full # 显示完整栈含局部变量 (gdb) info registers # 查看寄存器状态定位崩溃点 (gdb) x/10i $pc # 查看当前指令附近汇编我曾用x/10i $pc发现某次崩溃并非代码逻辑错误而是 CPU 微码缺陷导致movaps指令在特定 AVX 寄存器状态下触发非法操作——这种深度信息pstack 永远无法提供。技巧二pstack 输出的“时间戳”陷阱pstack 打印的#0 0x00007f8b4b8e1a1d in __lll_lock_wait ()中的地址0x00007f8b4b8e1a1d是进程虚拟地址不是绝对物理地址。若你想在另一台机器上反查这个地址对应的源码行必须满足两台机器运行完全相同的二进制文件md5sum 一致且该二进制是非 ASLR 编译或你记录了本次加载的基址验证方法# 查看目标进程的内存映射基址 cat /proc/$TARGET_PID/maps | grep libc.so.6 # 输出7f8b4b7a0000-7f8b4b920000 r-xp 00000000 08:02 123456 /lib/x86_64-linux-gnu/libc.so.6 # 其中 7f8b4b7a0000 是 libc 加载基址 # pstack 中的 0x00007f8b4b8e1a1d 减去基址 0x141a1d即 libc 内部偏移技巧三批量抓取多进程栈的防抖脚本线上服务常有多个 worker 进程逐个 pstack 效率低且易漏。以下脚本可安全批量采集#!/bin/bash # batch-pstack.sh - 安全批量抓取进程栈 TARGET_CMDnginx # 替换为目标进程名 OUTPUT_DIR/tmp/pstack-$(date %s) mkdir -p $OUTPUT_DIR # 获取所有匹配进程 PID排除自身和父 shell PIDS$(pgrep -f $TARGET_CMD | grep -v $$ | head -n 10) for PID in $PIDS; do # 检查进程是否存活且可访问 if kill -0 $PID 2/dev/null; then echo Capturing stack for PID $PID... sudo pstack $PID $OUTPUT_DIR/pstack-$PID.log 2$OUTPUT_DIR/pstack-$PID.err # 添加时间戳和进程信息 echo Process Info $OUTPUT_DIR/pstack-$PID.log