macOS 进程排查：功能组中只有 Running 状态，App 是如何被拉起的？

大概一年前，我在一台 Mac 上遇到一个挺诡异的现象：某个 App 的窗口都没出现在 Dock 里，进程却一直活着。我用ps看了一眼它的 functional group，发现这个功能组里只有一个进程，状态一直是 R。正常情况下，一个 GUI App 进入事件循环之后，状态应该稳定在 S，也就是 Sleeping，等在那里接收鼠标、键盘和系统事件；它既没有窗口、也没有明显后台任务，却一直维持 Running，这就有问题了。

标题里问的“如果一个 APP 的 Functional Group 的 states 里只有 Running，它是怎么被拉起的”，恰好就是我当时想搞清楚的问题。要回答它，得拆成三件事来看：功能组到底是什么、Running 状态意味着什么、进程的启动路径有哪些。下面结合我的排查过程，把这套思路完整讲一遍。

1. 先搞清楚 Functional Group 和 Running 状态到底在说什么

1.1 macOS 进程模型里的功能组到底是什么

在 macOS 上，除了大家熟悉的 PID、PPID、UID 这些进程属性之外，还存在一个容易被忽略的字段：functional group，功能组。你可以用一条很简单的命令直接看到它：

ps -Ao pid,ppid,funcgrp,state,command | head -20

输出里funcgrp那一列就是功能组 ID。功能组的引入，是为了把一组彼此相关的进程聚合起来统一管理。一般来说，一个进程通过posix_spawn从某个“leader”进程衍生出来时，会创建或者加入一个功能组，之后所有fork和exec出来的子进程默认继承同一个功能组 ID。这个机制在 XPC、App Sandbox、资源归属这些场景里被系统大量使用。

这里要特别区分开：功能组 ID 不是 PID，也不是进程组 ID（PGID）。它更像一个“家族标签”，用来表示“这些进程算同一个家族的”。在排查进程时，很多人只看 PPID，却忽略了功能组这个维度，结果把一些继承关系搞错。实际上，两个进程哪怕 PPID 不同，只要功能组 ID 相同，它们很可能来自同一个根进程；反之，PPID 相同但功能组不同，则说明子进程在启动时主动切了组，比如 XPC service 就经常这么干。

1.2 “只有 Running”为什么值得警惕？正常 GUI App 应该是 Sleeping

macOS 的进程状态常见的有 R（Running）、S（Sleeping）、I（Idle）、T（Stopped）、Z（Zombie）。如果你连续几次用ps -o state去看一个正常 GUI App 的主进程，绝大多数时候都会看到 S，因为它在事件循环里等待消息，处于“待机”状态。只有在处理事件、做密集计算、或者刚启动还没进入事件循环的那一小段时间里，它才会是 R。

所以，当你的监控输出显示“这个 functional group 里所有进程的状态都是 Running”时，至少能推断两件事：

1. 这个功能组内当前没有其他 Sleeping/Idle 状态的辅助进程，很可能是“光杆司令”。
2. 组里的那个进程正处在可运行队列中，要么在密集干活，要么刚刚被创建、还没来得及睡眠。

对排查启动链路来说，这是一条非常关键的时间线索：一个刚被拉起来的进程，往往会在初始化阶段保持一段 R，等初始化完成、进入事件循环或等待状态之后才变成 S。换句话说，“只有 Running”这个快照，很可能意味着你观察到的时机非常接近它的启动瞬间，或者这个进程启动之后一直在忙。

2. App 被拉起的五条主流路径：从 launchd 到 XPC

2.1 launchd / LaunchServices：用户点击和系统启动的主通道

在 macOS 上，一个 App 最常见、也最容易误判的启动方式，是经 launchd 间接拉起。用户双击 Finder 里的 .app、点击 Dock 图标，或者执行open -a AppName，并不会像终端里那样产生一个直接的fork父子关系。真正的动作是 LaunchServices 解析 App bundle、向 launchd 注册一个 job，然后由 launchd 调用posix_spawn把进程拉起来。

这种情况下，进程的 PPID 通常为 1，也就是 launchd。它的功能组往往是新建的，组内一开始只有一个进程，状态从 R 起步，然后很快进入 S。如果你遇到一个 functional group 里只有 Running 的进程，而它的 PPID 又是 1，那有相当大概率走的是这条路径。

需要提醒的是，PPID=1 不代表“系统启动它”的意图是开机自启。LaunchServices 拉起 App 后会把进程交给 launchd 托管，父进程统一变成 1，所以不能只看父进程就断定是 LaunchAgent 干的。

2.2 XPC service：按需拉起、用完即走的幕后 helper

很多 App 会把辅助功能拆成 XPC service，比如处理网络、解析文件、访问安全存储。XPC service 最大的特点是按需启动：别的进程通过xpc_connection_create连接它的 endpoint 时，launchd 才会把这个 service 拉起来。处理完请求、连接断开后，它又可能被系统回收退出。

这种 helper 启动时，functional group 通常和主 App 的功能组不同，甚至是一个全新组。如果它正在处理请求，状态就是 R；如果处理完在等下一个请求，就变成 S。所以当你看到一个功能组里只有 Running 状态的进程，且父进程指向另一个 App，那很可能就是这个 XPC helper 恰好被唤醒、正在干一件一次性任务。用sample采样它，经常能看到调用栈停在某个xpc_connection_send或者文件读取上。

2.3 父进程 fork/exec：终端和自动化脚本的直拉方式

如果进程的 PPID 不是 1，而是某个 shell、脚本或另一个 App，那它就是父进程通过fork+exec直接拉起的。比如你在终端里手动运行：

/Applications/Example.app/Contents/MacOS/Example

这样启动的 App，功能组会继承终端进程的功能组，根本不会出现新的功能组 ID，除非 App 内部显式调用posix_spawn并传了创建新组的 flag。从排查角度说，如果你发现目标进程的 funcgrp 和当前 shell 的 funcgrp 完全一致，那基本就锁定了“手动或脚本直接执行”这条路径。

2.4 URL scheme、通知、后台任务：被系统事件唤醒

还有一类启动方式不是用户主动点击，而是系统事件唤醒。macOS 上常见的有通知响应、open一个myapp://链接、共享菜单、登录恢复等。这类启动最终仍然会走 LaunchServices/launchd 代为拉起，所以从进程表上看依然是 PPID=1、新功能组。

区别在于启动上下文会带上 URL、payload 或触发原因。如果进程被 URL scheme 唤起，它在argv或 Apple Event 里会带上那个链接；如果是通知响应，系统日志里会有对应 trigger。只靠ps看不出来，必须翻日志或者检查进程启动时的 Apple Event 参数。

2.5 判断方法：看父进程链和启动上下文

把上面的路径汇总一下，拿到一个未知进程后，我的固定操作是三步：

1. 看ps -o ppid：如果 PPID=1，说明经过 launchd / LaunchServices；如果不是，就沿着 PPID 继续往上找调用者。
2. 看ps -o funcgrp：确认它是不是独立功能组，还是和调用者共享功能组。
3. 翻日志：用log show搜这个进程名，找启动事件里的 trigger 字段，区分点击、URL scheme、XPC 还是 LaunchAgent 配置。

这样三步走下来，基本能还原一条完整的启动链路。配合下文要讲的命令，定位只是时间问题。

3. 实测排查：用一条命令链坐实拉起源头

3.1 ps：第一手现场信息

假设进程名叫 MyApp，第一步永远是拿基本信息：

ps -Ao pid,ppid,funcgrp,state,command | grep -i myapp

如果匹配出来多个结果，说明这个 App 有多个进程。这时我想看“整个功能组里到底有谁、状态分别是什么”，就需要先把目标功能组 ID 取出来，再过滤一遍：

fgid=$(ps -Ao pid,funcgrp,comm | grep -i myapp | awk '{print $2}' | head -1) ps -Ao pid,ppid,funcgrp,state,command | awk -v fg="$fgid" '$3 == fg'

第二行输出的每一行，都是同一个功能组里的进程。如果只有一行、状态列是 R，那就非常符合标题描述的场景：这个组是独立新组、只有一个进程、且处于 Running。注意head -1是关键，如果 App 有多个不同功能组的进程，不取第一个可能会过滤到空。

3.2 launchctl：launchd 视角的注册信息

launchd 是 macOS 的 1 号进程，几乎所有 GUI App 都跟它有关。launchctl提供了一个很实用的进程级接口：

launchctl procinfo <pid>

输出里能看到这个进程对应的 launchd job 名称、可执行文件路径、启动次数、是否 keepalive、sandbox 状态等。如果进程是由某个 LaunchAgent 或 LaunchDaemon 配置拉起的，这里会直接出现对应的 plist 路径，答案当场就出来了。

如果你知道 App 的 bundle id，也可以直接看它的 job 注册情况：

launchctl print gui/$(id -u)/com.example.MyApp

注意：有些 App 没有显式 LaunchAgent 配置，LaunchServices 也会在 launchd 里动态维护一个 job，所以procinfo里能看到记录，但磁盘上未必找得到对应 plist。这一点经常把人带偏，别一看有 job 就去翻 Library/LaunchAgents。

3.3 log show：从启动日志里找线索

系统日志里会记录不少进程启动事件。想还原启动瞬间，可以用：

log show --last 10m --predicate 'process == "MyApp" OR eventMessage CONTAINS[c] "MyApp"'

重点看包含exec、launchd、LaunchServices、XPC字样的条目。日志里经常有类似LaunchServices: registering app ...、launchd: execing ...、xpc: connection ...的记录，能从时间线上拼出是谁发起的。

我踩过的坑是：log show输出量大到吓人，尤其是进程名比较短（比如a、x）的时候，过滤条件会把大量无关日志捞进来。建议先确认准确的进程路径，再用process == "完整路径"精确过滤，或者先只取最近 1 分钟，跑一轮再说。

3.4 dtrace/fs_usage：抓到 exec 的那一刻

如果日志还是拼不出完整链路，可以挂上进程执行监控，等它再次被拉起时看现场。最简单的做法是用系统自带的fs_usage：

sudo fs_usage -e exec -w

它会实时打印所有exec系统调用，包括可执行文件路径、调用者 PID 和调用时间。你看到posix_spawn事件里出现了 MyApp，再顺着调用者 PID 去查是谁，就能抓住“拉起的瞬间”。

如果环境里装了 Xcode 命令行工具，execsnoop这个 dtrace 脚本也很好用：

sudo execsnoop

它专门跟踪新进程执行，会打印父进程 PID、子进程 PID 和完整命令行。这个工具特别适合排查“刚才明明没人操作，App 却自己起来了”的悬案，也比fs_usage的输出更容易读懂。不过要注意，在某些系统版本里 dtrace 因为安全策略会受限，执行不了就换回fs_usage。

3.5 一张表快速对照

4. 为什么“只有 Running”是个重要信号：进程状态的物理意义

4.1 从调度器视角看 R/S 状态

在 macOS 内核里，进程状态 R 表示它已经在调度器的可运行队列中，一旦有空闲 CPU 就能获得执行；S 表示它在等待某个事件，比如 I/O 完成、计时器到期、锁释放、消息到达，不在可运行队列中。

用生活化的方式理解：R 状态相当于一个人手里一直有活、在排队等工位；S 状态则是人坐在工位上等邮件通知，邮件不来就一直打盹。一个 GUI App 的绝大多数线程都在mach_msg里等事件，所以进程整体状态长期是 S。如果它长期是 R，常见原因有无限循环、忙等待、频繁轮询、动画渲染没有按 VSync 节拍走反而靠 runloop 空转等。

这个认知在排查 CPU 飙升时非常有用。我处理过一个案例：某个监控工具进程状态始终是 R，CPU 拉满，一开始以为是恶意程序，sample一看，线程栈全在dispatch_semaphore_wait和轮询 socket，原来是它自己代码里的一个死循环。

4.2 功能组内进程集合的意义

功能组里进程的状态组合，其实能反应一个 App 当前的整体“工作节奏”。如果一个组里只有 R，说明这个组整体一直在忙；如果一个组里既有主进程的 S，又有 helper 的 R，说明主进程负责事件循环、helper 正在执行一次性任务；如果组里全是 S，说明全家都在待命，这是最安静的常态。

回到标题的场景：“states 里只有 Running”，意味着这个功能组里没有 S 的“值守者”，这很不寻常。正常 GUI App 主进程通常在 S 状态等事件，除非它刚被拉起还在做初始化、或者彻底进入了密集计算。所以“只有 Running”这个快照本身，就强烈暗示“这个进程刚被创建不久，或者还没进入正常的事件等待周期”。

4.3 从快照逆推启动链路

把状态快照、父进程、功能组 ID、CPU 占用这几项放在一起，可以做一个简单的逻辑推导：

• 状态 R + CPU 高 + 功能组独立 + PPID=1，多半是 LaunchServices 拉起的，而且启动后立刻进入重活任务。
• 状态 R + CPU 低 + PPID 指向另一个 App，多半是 XPC helper 在响应一个轻量请求，刚被唤醒。
• 状态 R + 功能组与 shell 的 funcgrp 相同，基本就是你或某个脚本手动执行了二进制。
• 状态 R + PPID=1 + 功能组里有多个进程但其他状态是 S，说明主进程或某个 helper 正在忙，但家族整体仍有人值守。

这套推导不需要看内核源码，只要把状态快照和父进程链多采集几次，就能建立直觉。越往后排查，你会越习惯拿“状态的瞬时性”和“功能组的归属”这两个维度一起来看问题。

5. 容易被误判的场景和我的实操心得

5.1 误把 launchd 当作唯一拉起源

很多人看到 PPID=1 就认定是 launchd 配置的 LaunchAgent 拉起的，但实际很可能是用户点了一下 Dock 图标。launchd 在这里只是执行者，不是发起者。要区分这两者，必须看日志里的 trigger 字段，或者是launchctl procinfo里显示的 job 来源。凡是动态注册的 job，来源一般标注为 LaunchServices；而显式配置的 job，会带上 plist 文件路径。多验证一层，比猜准得多。

5.2 功能组可能被显式修改或合并

不要以为 functional group 一定和 App 严格对应。部分系统服务、XPC 容器框架可能把多个进程合并到同一个功能组里；反过来，一个 App 也可以主动创建多个功能组。所以“这个 functional group 只有一个进程”不代表“这个 App 整体只有一个进程”。正确的做法是同时列出该 App 的所有相关 PID，逐一比对功能组 ID，而不是盯着一个组下结论。

5.3 采样时机造成的假象

进程状态是瞬时的。一个进程可能在 99% 的时间里是 S，恰好在你ps的那几十毫秒里是 R，就会造成“这个进程一直在 Running”的错觉。正确做法是连续采样：

for i in {1..10}; do ps -Ao pid,funcgrp,state,comm | grep -i myapp; sleep 1; done

如果 10 次里全都是 R，才说明它真的持续在跑。如果只是偶尔蹦出 R，那它就是正常事件处理过程中的常见闪烁，不必过度解读。

5.4 命令行工具的局限与替代方案

fs_usage和log show都需要一定权限和过滤技巧，dtrace在某些系统上因为安全策略开不了。如果现场环境不允许这些工具，我的替代方案是用 Objective-C/Swift 写一个小工具，通过proc_pidinfo直接读取目标进程的功能组和状态。核心思路是遍历进程列表，过滤符合条件的功能组 ID，然后每秒刷新一次状态。

大致代码逻辑是这样的：

// 伪代码，核心是 proc_listallpids + proc_pidinfo int32_t pids[1024]; int count = proc_listallpids(pids, sizeof(pids)); for (int i = 0; i < count; i++) { struct proc_bsdinfo bsd; if (proc_pidinfo(pids[i], PROC_PIDTBSDINFO, 0, &bsd, sizeof(bsd)) > 0) { // bsd.pbi_status 就是状态，pbi_fg 对应功能组 if (bsd.pbi_fg == targetFG) { printf("pid=%d status=%d\n", pids[i], bsd.pbi_status); } } }

这种方式的优势是采样频率可控、输出干净，而且不依赖外部命令，适合做成常驻监控脚本。缺点是需要用开发者权限编译运行，但作为最后手段很可靠。

说到底，定位一个“只有 Running”的进程是怎么被拉起的，核心就三样：功能组归属、状态快照、父进程链。把这个三角信息采集齐了，再用日志和行为事件去补上下文，拉起源头几乎不可能漏掉。我后来再遇到类似的“幽灵进程”，已经不会慌着翻各种配置了，而是先跑一遍ps -Ao pid,ppid,funcgrp,state,command，然后连续采样几次状态。这个习惯帮我省下过太多时间，也推荐你下次遇到这个问题时，从这条命令开始。