# 在腾讯云 OpenCloudOS 9 上部署OCManager 部署踩坑解决：apk 卡住了 50 分钟一次进程「僵而不死」的完整排查方法论

> 这个坑我在 OCManager 部署时踩过一次，但这篇文章**不谈 OCManager**——我想把它抽出来当**教学案例**：当一个进程明明存活、CPU 却是 0，你怎么一步步定位它到底在等什么？本文从 `ps` 一路走到 `strace`，全程贴真实终端输出。同样的方法用来排查 `apt`、`yum`、`pip`、`curl`、`git clone` 无响应完全通用。
> 
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/7b3e6987326d298b01bbe0dfa12f7628.png)


## 一、现场：进程还活着，但什么都没在做

事情从一次镜像构建开始。Dockerfile 里再普通不过的一行：

```dockerfile
RUN apk add --no-cache gcc musl-dev
```
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/ef57b18119c87def8a320e92f481897c.png)

BuildKit 的进度条转啊转，从 `Installing binutils` 之后再无输出。5 分钟、10 分钟、30 分钟……**50 分钟仍在同一步**。

进程没死。但，也没在动。

这种「僵而不死」的状态最让人抓狂——Ctrl+C 之前，我先想搞明白**它到底在等什么**。这也是本文想讲的：**Linux 给我们的工具，足够让"看不见的等待"变得看得见**。
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/e6d86f4cb03bf6822eb8efe6c2aba138.png)

## 二、第一层：`ps` —— 先定性

任何进程排查的第一件事：拿到 PID，看它的**状态**和**CPU 占用**。

![ps 定性](https://developer.qcloudimg.com/http-save/yehe-10730009/bc137b608d6ba7084ef0f3978dcb8469.png)

```bash
$ ps -o pid,ppid,etime,stat,pcpu,pmem,cmd -p 704734
    PID    PPID     ELAPSED STAT %CPU %MEM CMD
 704734  704711       00:39 Ss    0.0  0.1 apk add --no-cache gcc musl-dev
```

信息量比 `ps aux` 少但精确。关键两列：

- **`STAT` = `Ss`**：`S` 是 **可中断睡眠**（interruptible sleep），意味着进程正在**等一个内核事件**——最常见是 I/O 或信号。`s` 是 session leader，跟本次排查关系不大。
- **`%CPU` = 0.0**：不是死循环、不是死锁自旋，是**真的在等**。

排除项：

| 表现 | STAT | 排查方向 |
| --- | --- | --- |
| 死循环 CPU 100% | `R` (running) | perf top / py-spy / pprof 找热点 |
| 无响应 CPU 0% | `S` / `D` | **本文场景**，往下找它在等什么 |
| 变僵尸 | `Z` | 找父进程为什么不 wait |
| 不可中断睡眠 | `D` | 通常磁盘 I/O 卡死，几乎打不断 |

我们这里是 `S` + 0% CPU，明确指向**"在等某个事件被唤醒"**。下一步是搞清楚：等的是什么事件？

## 三、第二层：`/proc/<pid>/status` 和 `wchan` —— 内核在等哪个函数

Linux 把内核的许多状态直接暴露在 `/proc/<pid>/` 下，读文件就行，不需要装任何工具。

![/proc 状态](https://developer.qcloudimg.com/http-save/yehe-10730009/d6cecd15d72d03c5d0a9a902c20536d9.png)

```bash
$ grep -E '^(Name|State|Pid|PPid|Threads):' /proc/704734/status
Name:    apk
State:   S (sleeping)
Pid:     704734
PPid:    704711
Threads: 1

$ cat /proc/704734/wchan
wait_woken
```

**`wchan`** 这个字段太少人用了。它显示进程当前**在内核态的哪个函数上睡着**：

- `wait_woken` / `sk_wait_data` / `inet_csk_accept` → **网络等待**
- `io_schedule` / `blk_mq_get_tag` → **磁盘 I/O 等待**
- `futex_wait_queue_me` → **锁等待**（用户态互斥）
- `pipe_wait` → **管道等待**

我们这里是 `wait_woken`，进一步收窄：**在等网络 socket 数据到来**。

到这里，一个 `ps` + 一次 `cat`，还没启动任何监控工具，问题已经被定位到「网络等待」这个粒度。剩下的问题：**等哪条连接？等谁？**

## 四、第三层：`/proc/<pid>/fd` —— 进程握着哪些资源

**每个进程打开的文件、管道、socket，都在 `/proc/<pid>/fd/` 里以符号链接形式列出**。这是 Linux 最优雅的设计之一。

![fd 表](https://developer.qcloudimg.com/http-save/yehe-10730009/07880ca0a24c71e6f82bc4982349d965.png)

```bash
$ ls -l /proc/704734/fd/
total 0
lrwx------ 1 root root 64 Jul  8 13:18 0 -> /dev/null
l-wx------ 1 root root 64 Jul  8 13:18 1 -> pipe:[3665273]
l-wx------ 1 root root 64 Jul  8 13:18 2 -> pipe:[3665274]
lr-x------ 1 root root 64 Jul  8 13:19 3 -> /
lrwx------ 1 root root 64 Jul  8 13:19 4 -> /lib/apk/db/lock
lr-x------ 1 root root 64 Jul  8 13:19 5 -> /var/cache/apk
lr-x------ 1 root root 64 Jul  8 13:19 6 -> /etc/apk/keys
lrwx------ 1 root root 64 Jul  8 13:19 7 -> socket:[3665421]
```

一眼扫过去：

- `fd 0/1/2`：标准输入/输出/错误
- `fd 4`：apk 数据库锁
- `fd 5/6`：包缓存和签名目录
- **`fd 7`：一个 socket，inode 是 `3665421`** ← 这是我们要追的

结合上一层的结论（`wchan = wait_woken`，等网络），几乎可以肯定进程就是在等 `fd 7` 这个 socket 的数据。**只剩最后一个问题：这个 socket 连到了哪里？**

## 五、第四层：`/proc/<pid>/net/tcp` —— 十六进制反解出对端

`/proc/net/tcp` 是内核暴露的 TCP 连接表原始视图，`ss` 和 `netstat` 都是从它读的。字段是十六进制的，看起来吓人，但一旦你会看，比任何工具都直接。

![十六进制反解](https://developer.qcloudimg.com/http-save/yehe-10730009/aa4f041fc44ff7767400ceca50b2ccb6.png)

```bash
$ head -1 /proc/704734/net/tcp
  sl  local_address  rem_address  st ...  uid  timeout  inode

$ awk '$4=="01"' /proc/704734/net/tcp | grep 3665421
  0: 020011AC:9788 84724B92:01BB 01 ... 0 0 3665421 ...
```

四个要点：

1. **`$4=="01"`** 过滤：TCP 状态码 `01` = `ESTABLISHED`（已建立），常用的还有 `0A`=LISTEN、`06`=TIME_WAIT。
2. **匹配 inode `3665421`**：跟 fd 7 对上，确认是同一条连接。
3. **`local_address` = `020011AC:9788`**：本地。
4. **`rem_address` = `84724B92:01BB`**：远端——**这就是我们要的答案**。

十六进制反解，两个坑：

- **IP 需要反字节序**：`84 72 4B 92` 是**小端**存的，反过来是 `92 4B 72 84` → 十进制 `146.75.114.132`。
- **端口是大端**：`01 BB` 直接转十进制 = **443**。

一行 Python 搞定：

```bash
$ python3 -c 'h="84724B92";print(".".join(str(int(h[i:i+2],16)) for i in (6,4,2,0)))'
146.75.114.132
```

**远端 `146.75.114.132:443` 就是 apk 卡住的对象**。这个 IP 反查会指向 Fastly CDN——`dl-cdn.alpinelinux.org` 走的正是 Fastly，与我们的猜测（Alpine 官方源）对上了。

## 六、辅助工具：`nsenter` 让宿主直接看容器内的 socket

上面全流程在**宿主机**完成，但如果进程在容器里，`ss` 默认看到的是宿主的 network namespace，看不到容器里的连接。老办法是 `docker exec <c> apk add net-tools`，装工具又慢又污染镜像。

更专业的做法是 **`nsenter -t <pid> -n`**：临时借用目标进程的 network namespace，宿主的 `ss` 就能直接查容器内连接。

![nsenter 抓连接](https://developer.qcloudimg.com/http-save/yehe-10730009/46f3aa26c18af8648d8f75bd0008791e.png)

```bash
$ nsenter -t 704734 -n ss -tnp
State  Recv-Q Send-Q Local Address:Port    Peer Address:Port  Process
ESTAB       0      0    172.17.0.2:38792  146.75.114.132:443
                       users:(("apk",pid=704734,fd=7))
```

一行输出把结论说全了：容器内 apk（PID 704734, fd 7）从 `172.17.0.2:38792` 连到 `146.75.114.132:443`，状态 `ESTABLISHED`。跟前面从 `/proc` 手挖出来的结果**完全一致**——你也可以把 `nsenter` 当"抄近路"，跳过十六进制反解那步。

两条路都能走，值得都会——`nsenter` 快，`/proc` 底子扎实、在极简环境下也能用（比如 Alpine minimal 里可能连 `ss` 都没有）。

## 七、最后一击：`strace` 佐证「在慢速 read」

到这里问题已经定位得差不多。要不要打开 `strace` 看一眼？我的原则是：**当你想验证"是不是真的每次都读一点点"**，`strace` 是决定性证据。

```bash
$ timeout 5 strace -p 704734 -e trace=network,read,write 2>&1 | tail -12
```

![strace 佐证](https://developer.qcloudimg.com/http-save/yehe-10730009/79e4beb20c4abd0fcc54399ce0e2c236.png)

5 秒采样里，`read(7, ...)` 循环调用了 10 多次，每次返回 **1074 ~ 4236 字节**——都是被 TCP MSS 卡住的小包。这说明：

- 连接是**通的**（没到 timeout / RST）
- 但**带宽被压得很低**，每读回 1.4KB 就得再等下一批数据
- 累积起来，几十 MB 的 gcc 依赖能拖上小时级

到这里，所有证据链闭合：**进程正常运作，只是网络路径的带宽让它慢到肉眼看不到进度**。

## 八、定罪：一次直连对比

排查到 socket 层其实已经够。但如果你要写复盘、要说服别人（或说服自己不要再折腾其它可能性），最有力的证据是**替换变量做对比**。

![定罪测速](https://developer.qcloudimg.com/http-save/yehe-10730009/f1e822677bc361232d7aee8483ef2dbe.png)

```bash
# 直连 Alpine 官方 CDN
$ curl -so /dev/null -w 'time=%{time_total}s speed=%{speed_download}B/s\n' \
       --max-time 15 https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
time=15.000127s speed=19938B/s        <- 19 KB/s，15 秒还没下完

# 换腾讯云 Alpine 镜像
$ curl -so /dev/null -w 'time=%{time_total}s speed=%{speed_download}B/s\n' \
       --max-time 15 https://mirrors.tencent.com/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
time=0.296236s speed=1580594B/s       <- 1.5 MB/s，296 毫秒完成
```

**19 KB/s vs 1.5 MB/s，约 80 倍差距**。gcc 依赖链在 Alpine 官方 CDN 上要 50 分钟没跑完，换个源 7 秒搞定。

## 九、把它变成一个可复用的排查流程

回头把整个过程抽象一下：

```text
                     进程无响应？
                          │
                     ┌────▼────┐
                     │   ps    │  看 STAT 和 %CPU
                     └────┬────┘
              CPU=0 (S)  │  CPU=100% (R)
              ───────────┼──────────────
                         │                       perf top / py-spy
              /proc/<pid>/wchan  ────► 内核态在等哪个函数
                         │
             wait_woken 网络   io_schedule 磁盘   futex_wait 锁
                         │
              /proc/<pid>/fd/  ────► 找到相关的 fd（socket / file）
                         │
            /proc/<pid>/net/tcp 或 nsenter+ss ────► 找到对端 IP:PORT
                         │
                     strace 采样   ────► 佐证是"慢速 read"还是"完全阻塞"
                         │
                    curl 直连对比 ────► 定罪，进入修复
```

这套流程的价值不在于每个工具本身——它们都是老工具。价值在于**顺序**：**先廉价 (`/proc` 一堆 `cat`)、再中等 (`nsenter`+`ss`)、最后昂贵 (`strace` 会短暂暂停目标进程)**。这样你在 90% 情况下用不到 `strace` 就能收工，剩下 10% 用 `strace` 也是有的放矢。

## 十、几点延伸

**为什么不一上来就 `strace`？**
`strace` 通过 `ptrace` 附加，会让目标进程慢 5-100 倍。在生产环境上对正在服务的进程用 `strace`，等于二次伤害。先看 `/proc` 是完全零成本的（甚至连 root 都不一定需要），能不动进程就别动。

**为什么不用 `netstat`？**
`netstat` 依赖 `net-tools` 这个已经不再维护的包，很多 minimal 镜像不装。`ss` 是 iproute2 的一部分，几乎无处不在，且更快（`ss` 直接读 netlink，`netstat` 挨个读 `/proc/net/*` 文本）。

**Alpine 官方 CDN 是不是永远慢？**
不是。Fastly 在境内没有节点，出境走的是国际链路，晚高峰不稳定，有时也能秒过。这种"有时快有时几乎不动"最难排查——你以为是自己的问题。所以**"排查到 ESTABLISHED + 慢速 read"这一层，就足够下判断了**，剩下的换源解决即可，不必去和链路较劲。

**Docker 镜像加速能救吗？**
不能。Docker registry 镜像加速只作用于 `docker pull` 拉镜像层的过程，容器内跑的 `apk` / `apt` / `yum` 走的是发行版自己的 HTTP 仓库，跟 Docker registry 是两套系统——这是国内很多开发者踩过的坑，值得单独记一下。

## 十一、写在最后

这次排查花的**总时间不到 5 分钟**（不含 apk 本身卡住的 50 分钟），但如果没有这套顺序，很多人的第一反应是「重启一下试试」或「重新构建一次说不定就好了」——把 50 分钟浪费在赌运气上。

Linux 把内核状态几乎全部通过 `/proc` 暴露，是 UNIX 哲学里最好的一段：**万物皆文件**。你不需要装任何工具，一个 `cat` 就能问内核："这家伙在等什么？"。

下次遇到进程无响应，你的第一反应可以不再是「杀了重启」，而是：

```bash
ps -o pid,stat,pcpu,cmd -p <pid>
cat /proc/<pid>/wchan
ls -l /proc/<pid>/fd/
cat /proc/<pid>/net/tcp
```

四个命令，多数问题就有了方向。

**本文命令均可在 CentOS/Rocky/OpenCloudOS/Ubuntu 上直接运行**（`nsenter` 需要 root，`strace` 需要 CAP_SYS_PTRACE）。排查对象是 `apk`，但换成 `apt`、`yum`、`curl`、`git`、Python 任意卡住的进程，方法完全一致。


这个坑我在 OCManager 部署时踩过一次，但这篇文章不谈 OCManager——我想把它抽出来当教学案例：当一个进程明明存活、CPU 却是 0，你怎么一步步定位它到底在等什么？本文从 ps 一路走到 strace，全程贴真实终端输出。同样的方法用来排查 apt、yum、pip、curl、git clone 无响应完全通用。

在腾讯云 OpenCloudOS 9 上部署OCManager 部署踩坑解决：apk 卡住了 50 分钟一次进程「僵而不死」的完整排查方法论

服务端开发

运维

操作系统

后端

本文详细解析了Linux进程卡顿的排查方法，通过ps、/proc、wchan、strace等工具层层深入，定位到网络等待问题。适用于apk、apt、yum等命令卡顿场景，提供了一套高效的问题定位流程，帮助开发者快速解决进程"僵而不死"的问题，避免盲目重启浪费时间。

代码解释

数据库

容器

Python

CentOS

Ubuntu

Linux

2026上云采购 | AI焕新·智启新局

CDN免费试用


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在腾讯云 OpenCloudOS 9 上部署OCManager 部署踩坑解决：apk 卡住了 50 分钟一次进程「僵而不死」的完整排查方法论-腾讯云开发者社区-腾讯云

在腾讯云 OpenCloudOS 9 上部署OCManager 部署踩坑解决：apk 卡住了 50 分钟一次进程「僵而不死」的完整排查方法论

在腾讯云 OpenCloudOS 9 上部署OCManager 部署踩坑解决：apk 卡住了 50 分钟一次进程「僵而不死」的完整排查方法论

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐