Linux systemd-run 怎样把临时服务放进 scope

如果你只是想把当前命令及其子进程临时交给 systemd 管理，可以使用 systemd-run --scope。它创建的是临时 .scope 单元：命令由 systemd-run 自己作为父进程执行，继承调用者环境，并在命令结束后同步返回；systemd 仍然会把这组进程作为 unit 展示出来。

官方文档：https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html

先记住一个判断：需要长期脱离终端运行的后台任务，优先写成正式 .service；只是希望当前命令组临时纳入生命周期、资源或状态管理时，才用 --scope。

先从症状区分 service 与 scope

很多“命令明明启动了，为什么退出方式不一样”的问题，根因不是参数拼错，而是 systemd-run 默认创建临时 .service，而不是 scope。默认 service 会由服务管理器作为父进程启动，通常异步返回；scope 则由 systemd-run 自己承载命令，继承当前调用环境，并同步等到命令结束。

这会形成两种典型症状：第一，使用默认模式时，当前 shell 很快拿到一个 unit 名，任务在后台继续；第二，使用 --scope 时，命令仍占用当前调用流程，但可以用 systemctl 找到整个进程组。二者都能被 systemd 管理，差异在于进程父子关系、环境继承和调用时序。

用 --scope 创建临时范围

最小命令是下面这样。示例使用 sleep 让范围保持一段时间，便于读者在另一个终端检查 unit；命令本身只是说明用法，不代表本文在本机执行过。

# 把当前命令放进临时 scope；sleep 结束后 scope 也会结束。
systemd-run --scope sleep 60

官方手册说明，--scope 会创建临时 .scope，而 scope 中的命令由 systemd-run 作为父进程执行。因此，环境变量、当前工作目录和终端关系更接近直接运行命令的效果。若只需要后台启动并让服务管理器接管启动过程，则省略 --scope，得到的是临时 .service。

可以给 unit 一个稳定、便于查找的名字：

# -u 只负责指定 unit 名；名称应以 .scope 结尾以表达目标类型。
systemd-run --scope --unit=demo-batch.scope sleep 60

# 给临时范围补充人类可读描述，方便 systemctl 输出识别。
systemd-run --scope --unit=demo-batch.scope \
  --description="临时批处理进程组" \
  sleep 60

如果你传入的命令包含 $，还要留意 systemd 的环境变量展开规则；不希望管理器展开时，可以显式使用 --expand-environment=no，并在 shell 引号层面保留真正要交给命令解释的内容。

用属性和 slice 限制范围

scope 不只是一个列表标签，它也可以承载 unit 属性。比如，临时压测任务不希望和普通业务进程争用 CPU 时，可以把它放进专门 slice，或直接传入资源属性：

# 将临时进程组放到专用 slice，便于统一查看和继续设置资源策略。
systemd-run --scope \
  --unit=load-test.scope \
  --slice=workload.slice \
  --property=CPUWeight=20 \
  sleep 60

--slice= 用于指定新 scope 所属的 slice；--property= 则按 systemctl set-property 使用的赋值格式设置创建出来的 unit 属性。属性名称是否适合你的发行版、systemd 版本和控制器配置，需要结合实际资源控制能力决定。

如果是用户自己的临时任务，可以用用户 manager，而不是系统 manager：

# 使用当前用户的 systemd --user manager，不要求把任务放入系统级 unit。
systemd-run --user --scope --unit=user-work.scope sleep 60

系统级 scope 往往需要相应权限；用户级 scope 则受用户 manager、登录会话和 lingering 配置影响。不要把 --user 当成权限绕过方式，它只是改变连接的服务管理器。

用 systemctl 定位运行状态

创建 scope 后，首先要确认 unit 是否真的出现在 manager 视图里，再判断命令和子进程的状态。下面是一组按顺序使用的查看命令：

# 查看指定 scope 的状态、主进程和最近日志摘要。
systemctl status demo-batch.scope --no-pager

# 只列出当前活动的 scope，避免把历史 service 混在结果里。
systemctl list-units --type=scope --state=active

# 查看 scope 对应的日志；实际日志内容由命令本身和日志配置决定。
journalctl -u demo-batch.scope -n 50 --no-pager

排障时看三件事：unit 名称是否与命令中指定的一致；scope 是否处于 active；主进程退出后，unit 是否随之变为 inactive。scope 用于描述当前进程组，不能像长期 service 那样期待它在机器重启后自动恢复。

按生命周期选择最终方案

把临时 scope 当成“当前进程组的 systemd 外壳”更容易做正确选择：

如果已经反复手写一长串 systemd-run 参数，或需要持久化依赖、安装、日志轮转和失败恢复，就说明它已经不是“临时范围”问题，应改为编写正式 service 单元。

结论：scope 解决的是临时纳管

1. systemd-run 默认创建临时 .service；--scope 才创建临时 .scope。
2. scope 由调用者环境启动并同步等待，systemd 仍负责展示和管理其中的进程组。
3. --unit、--description、--slice 和 --property 用于命名、识别和治理临时任务。
4. 需要持久生命周期、自动恢复或依赖关系时，停止堆叠命令行参数，改用正式 .service。

常见问题

为什么加了 --scope 后命令行没有立即返回？因为 scope 模式是同步的，systemd-run 会等命令完成；默认临时 service 则通常在启动请求完成后就返回。

scope 和 service 都能用 systemctl 查看吗？可以。它们都是 systemd unit，但类型和进程归属不同，可以分别用 systemctl list-units --type=scope 或 --type=service 查看。

--scope 能让进程重启后自动回来吗？不能把它当成持久化机制。需要开机启动、自动重启和依赖关系时，应写成正式 service 或配合 timer 等持久单元。