监控macOS后台服务异常重启需结合Console日志与launchctl状态：筛选com.apple.xpc.launchd子系统中含"exited"/"started"的日志，观察PID变更闭环；用log show命令抓取1小时内退出上下文，配合launchctl list检查PID波动及退出码；增设健康检查日志锚点实现业务不可用溯源。
要监控 macos 后台进程服务的异常重启事件，核心是结合 控制台（console）实时日志流 与 launchd 状态变化线索，而不是被动等崩溃发生后再查。关键在于捕获“进程退出→被 launchd 拉起”这一完整循环，并区分正常重启与异常抖动。
盯住 launchd 服务状态变更日志
launchd 不会主动上报“我刚重启了某个服务”，但每次服务启停都会在 Unified Logging 中留下痕迹。直接筛选这类信号最有效：
- 打开“控制台”App，左侧选中本机名称，顶部搜索栏输入：
subsystem == "com.apple.xpc.launchd" AND eventMessage CONTAINS "exited" OR eventMessage CONTAINS "started" - 重点关注带
PID变更的日志，例如com.example.service: exited with code: 1后紧跟着com.example.service: launched with pid: 12345—— 这就是一次异常重启闭环 - 若某服务在几分钟内反复出现“exited → started”，说明它正陷入启动失败循环，不是配置问题就是依赖缺失
用 log 命令抓取最近的重启上下文
图形界面可能延迟或过滤部分条目，终端命令能确保不漏掉关键瞬时记录：
- 运行：
log show --predicate 'subsystem == "com.apple.xpc.launchd" AND (eventMessage contains "exited" OR eventMessage contains "terminated")' --last 1h --info - 加上
--debug可看到更细粒度的退出原因（如 signal 6、exit code 137），这对判断是 OOM 被杀还是代码 panic 很关键 - 想关联到具体服务？把
com.example.service替换进 predicate：subsystem == "com.apple.xpc.launchd" AND eventMessage contains "com.example.service"
配合 launchctl list 观察 PID 波动
单纯看日志不够直观，需要和实时状态交叉验证：
- 终端执行：
launchctl list | grep com.example.service，记下当前 PID - 每 10 秒重复一次：
watch -n 10 'launchctl list | grep com.example.service' - 如果 PID 频繁变化（比如 30 秒内变了三次），而你没手动
kickstart或stop/start，基本可断定服务在后台自重启 - 注意看第三列退出码：
-表示还在跑；数字（如1、137）表示上次退出状态，非 0 就是异常退出
设置健康检查日志锚点便于回溯
很多服务“假死”——进程还在，但已不响应请求。此时 launchd 不会重启，但业务已中断。建议在健康检查脚本里主动打日志：
- 写一个检查脚本（如检测端口或调用 /health），开头加：
logger -t "health-check-com.example.service" "starting check" - 失败时加：
logger -t "health-check-com.example.service" "failed, restarting via launchctl" - 之后在控制台搜索
health-check-com.example.service，就能把业务不可用时间点和后续人工干预动作串起来
