2 篇博文 含有标签「Linux」

在用阿里云云助手 RunCommand 于服务器上拉起 strace 采样、watch 循环和定时采样器时，调用一返回，后台任务就被静默清杀——产出是空文件，或只有第 1 针的半截文件，全程无任何报错。

在为客户提供 WordPress 中国站全托管 时踩到阿里云云助手的一个隐蔽行为——整站迁移、图片上云、每日备份与自动巡检的长期托管服务。

TL;DR​

云助手调用结束会清理本次调用派生的后台进程，nohup 挡不住——它只忽略 SIGHUP 并重定向输出，进程仍留在原会话里，恰好在清理范围内。用 setsid 创建新会话才能逃出去：setsid nohup cmd < /dev/null &。回收产物前先验输出文件的行数与 mtime，别把空文件当成「命令没跑」。

问题现象：调用返回，后台任务静默消失​

同一条 RunCommand 里 nohup cmd & 拉起的后台任务，三种形态死给你看：

三种死法共享两个特征：调用本身返回成功（Success），服务器上无任何报错日志。搜「nohup 进程还是没了」「后台任务莫名消失」，答案大多指向 SIGHUP——但 nohup 明明已经加了。

根因：nohup 不换会话，清理按会话走​

nohup 的语义只有两条：忽略 SIGHUP、把输出重定向到 nohup.out。它不做的事是换会话——进程还在云助手 agent 为本次调用创建的会话里。调用收尾时，agent 清理本次派生的进程，按会话归拢，nohup 任务一个都跑不掉。

setsid 的语义才是对症的：为新进程创建全新会话，使其脱离调用会话。脱离之后，收尾清理扫不到它——实测 strace、采样器、watcher 三类任务换成 setsid 后全部存活。

一条诚实的边界：agent 内部按什么粒度清（进程组还是会话）未做源码级查证，但「脱离原会话即存活」这个充分条件在三类任务上实证一致，够用了。

解决方案：setsid 三件套 + 产出验证​

启动后台任务时，脱离会话、脱离终端、扔后台一步到位：

# 云助手脚本内拉起长时任务（采样器示例）
setsid nohup /usr/local/bin/sampler --interval 60 -o /tmp/samples.csv </dev/null >/tmp/sampler.log 2>&1 &

</dev/null 别省——后台任务的 stdin 若还挂在调用会话的终端语义上，存活了也可能停摆。

云助手是异步三段式（CreateCommand → InvokeCommand → DescribeInvocationResults），下发后约 10 秒再取结果；脚本里拉起后台任务后，脚本本身正常退出即可，不需要等任务。

回读产物前，先验任务是否真的活过：

# 行数应为预期针数；mtime 应持续推进
wc -l /tmp/samples.csv
stat -c %Y /tmp/samples.csv

空文件或只有第 1 针，说明任务没活下来——回去查 setsid 写法，而不是怀疑业务命令。这套「远程拉起、事后回读、先验产出」的流程，配合云助手留痕（ActionTrail）就是应急诊断的完整闭环。

这个教训反过来解释了服务器哨兵的架构口径：监控采集走机器上的常驻 agent 与本地 cron，备份脚本本地自跑、不依赖中心存活——长时任务的生命周期，不该绑在一次远程调用的收尾上。

常见问题​

nohup 启动的进程为什么还是没了？​

nohup 只做两件事：忽略 SIGHUP、重定向输出，进程仍留在原会话里。云助手调用结束时按会话清理本次派生的进程，nohup 任务恰好在清理范围内——实测 strace、采样器、watcher 三类任务全部被清，且调用本身返回成功、无任何报错。用 setsid 创建新会话才能逃出清理范围。

nohup 运行一段时间之后退出是怎么回事？​

常见因有三类：启动方会话收尾清理、stdin 挂在已关闭的终端上、输出重定向目标消失。判别看时间点——本例采样器只出第 1 针就停，消失时刻与云助手调用返回严格同步，据此锁定是调用方清理而非任务自身崩溃。

云助手 RunCommand 里怎么让脚本常驻后台？​

用 setsid、nohup、stdin 重定向三件套：setsid nohup cmd < /dev/null &。新会话不在调用收尾的清理范围内，任务跨调用存活。回收产物前先验产出文件行数与 mtime——空文件或半截文件说明任务没活下来，别把空结果当成命令没执行。

在编写服务器监控探活时，systemctl is-active redis-server 返回 inactive，但 Redis 实际正在正常服务请求。

在开发 AI 运营 时遇到此问题——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。监控面板需要准确实时反映各基础组件状态，而 Redis 的状态判断一开始就给出了错误信号。

TL;DR​

systemctl is-active 只对 systemd 通过 unit file 管理的服务 有效。如果 Redis（或任何服务）是裸进程启动，没有对应 .service unit，systemctl 永远查不到它的真实状态，返回 inactive（退出码 3）。可靠探活要绕开 systemctl，直接用 pgrep 查进程或 ss 查端口监听。

问题现象​

探活接口对 Nginx 和 Redis 同时调用 systemctl is-active：

$ systemctl is-active nginx
active            # ✅ 正常

$ systemctl is-active redis-server
inactive          # ❌ 看似 Redis 没跑
$ echo $?
3                 # exit code 3 = inactive

但所有业务接口都能正常读写 Redis，/api/v1/server-monitor/status 却报告 Redis 宕机。

根因​

systemd 是一个进程管理器，它只能感知自己启动和托管的单元（unit）。当你用 systemctl start redis-server 或让 systemd 读 redis-server.service 启动时，systemd 记录了该单元的状态，is-active 才能返回 active。

而这台服务器上的 Redis 是以裸进程方式启动的——直接运行 redis-server 或通过 nohup/自定义脚本拉起，并没有注册为 systemd 服务。于是：

• systemd 的单元列表里根本没有 redis-server.service；
• systemctl is-active redis-server 找不到该单元，按 inactive 处理，返回 exit 3；
• Nginx 相反，是标准的 systemd 服务，所以 is-active 正常命中 active。

一句话：is-active 查的是 systemd 视图，不是系统进程视图。进程在跑和 systemd 知道它在跑，是两回事。

解决方案​

探活逻辑改为「systemctl 主判断 → 进程/端口降级」的链式检测。systemctl 命中则直接采用；失败时用 pgrep 或 ss 兜底确认进程真实存活。用 execFileSync（不经过 shell、参数以数组传递）避免命令注入：

import { execFileSync } from "node:child_process";

/** 安全执行单条命令（不经过 shell），非零退出统一返回 null */
function sh(cmd: string, args: string[]): string | null {
  try {
    return execFileSync(cmd, args, {
      stdio: ["ignore", "pipe", "ignore"],
      timeout: 2000,
    })
      .toString()
      .trim();
  } catch {
    return null; // inactive / 进程不存在 / 超时 都走这里
  }
}

/**
 * 探活某服务是否在运行：systemctl 主判断，裸进程降级。
 * @param unit   systemd 单元名（如 "nginx"）
 * @param proc   进程名（如 "redis"），用于 pgrep 降级
 * @param port   监听端口（如 6379），用于 ss 降级
 */
function isServiceUp(unit: string, proc?: string, port?: number): boolean {
  // 1. 先走 systemctl（标准 systemd 服务）
  const st = sh("systemctl", ["is-active", unit]);
  if (st && st !== "inactive" && st !== "unknown") {
    return true; // active 或 activating/reloading 等中间态
  }

  // 2. 降级 A：pgrep 按进程名找 PID
  if (proc && sh("pgrep", ["-f", proc])) return true;

  // 3. 降级 B：ss 按端口确认监听
  if (port) {
    const listening = sh("ss", ["-lnt"]);
    if (listening && listening.includes(`:${port} `)) return true;
  }

  return false;
}

// Nginx：标准 systemd 服务，systemctl 直接命中
const nginxUp = isServiceUp("nginx");

// Redis：可能是裸进程，传进程名 + 端口兜底
const redisUp = isServiceUp("redis-server", "redis", 6379);

对应用层而言，更稳的最终确认是让服务自己回答——Redis 的 PING 命令、PostgreSQL 的 SELECT 1、HTTP 服务的健康检查端点。端口监听只能证明"进程起来了"，不能证明"服务 ready"，所以关键路径上建议再加一层应用层探活：

$ redis-cli ping
PONG    # 进程在跑 + 能响应 = 真正存活

常见问题​

为什么 systemctl is-active 显示 inactive 但进程实际在运行？​

systemctl 只查询 systemd 通过 unit file 管理的服务。如果进程是用 nohup 或直接命令启动的裸进程，没有对应 .service unit，systemd 既不认识它、也不追踪它，is-active 就只能返回 inactive（exit 3）。这是 systemd 视角的盲区，不是进程真的挂了。

怎么可靠检测一个进程是否在运行？​

不要只依赖 systemctl。用 pgrep <进程名> 查 PID，或 ss -lntp | grep <端口> 确认端口监听；这些命令查的是系统进程/网络栈，与是否被 systemd 管理无关。对关键服务，再加一层应用层探活（如 redis-cli ping），既验证进程存在又验证服务可响应。