systemctl start、enable、reload、restart、daemon-reload、reset-failed和mask有什么区别？

直接答案

start 让单元现在进入活动状态；enable 按单元安装信息建立开机或目标依赖关系，但通常不立即启动；reload 要求正在运行的服务重载自身配置；restart 停止后再启动服务；daemon-reload 让 systemd 管理器重新读取 unit 文件并重建依赖关系；reset-failed 清除 failed 状态以及相关启动限速计数；mask 把单元链接到 /dev/null，阻止各种方式启动它。

修改了服务自己的配置，通常考虑 reload 或 restart；修改了 .service、.socket、drop-in 等 unit 定义，先执行 daemon-reload。两者不是同一个“重载”。

七个命令对比

表中是核心语义。命令还可能带 --now、--runtime 等选项，选项会改变组合效果，执行前应查看实际命令而不是只看动词。

systemctl start做什么？

systemctl start name.service 向 systemd 管理器提交启动作业。systemd 会按照依赖与排序关系调度相关单元，并根据 Type=、ExecStart= 等配置判断服务何时进入 active 或启动失败。

start 不会自动把服务设为开机启动。机器重启后是否再启动，取决于 enable 建立的依赖、其他单元的 Wants/Requires、socket 或 path 激活、生成器以及管理员的其他配置。

执行成功只表示 systemd 的启动作业成功完成，不一定证明应用端到端健康。仍应检查 systemctl status、journalctl -u、监听端口和业务健康接口。

start和enable有什么区别？

start 回答“现在要不要运行”，enable 回答“在满足某个目标或激活关系时，是否被拉起”。一个服务可以 active 但 disabled，也可以 enabled 但当前 inactive。

systemctl enable --now name.service 是常见组合：先建立 enable 关系，并同时启动单元。排障报告应明确是否使用了 --now，否则“我已经 enable 了为什么没运行”往往只是语义误解。

systemctl enable做了什么？

enable 根据 unit 文件 [Install] 段中的 WantedBy=、RequiredBy=、Alias= 等信息创建符号链接。它并不是向 unit 文件写入 enabled=true，也不保证服务在任何启动环境中都会成功运行。

有些单元是 static，没有可用的安装信息，不能按普通方式 enable，但仍可被其他单元依赖或手动启动。generated、transient、indirect 等状态也各有含义，不能把所有非 enabled 都视作故障。

查看状态可使用：

systemctl is-enabled name.service
systemctl is-active name.service
systemctl status name.service

三个命令分别回答安装关系、当前活动状态和综合诊断信息。

disable会立即停止服务吗？

默认不会。systemctl disable 移除 enable 建立的链接，已运行的服务通常继续运行。需要同时停止时使用 disable --now，但仍应评估依赖方是否会再次启动它。

disable 也不等于禁止启动。用户仍可手动 start，其他 unit 也可能依赖并拉起它。要强制阻止激活，应理解并谨慎使用 mask。

systemctl reload做什么？

systemctl reload name.service 触发 unit 定义的服务重载操作，通常对应 ExecReload= 或支持通知协议的重载流程。其目标是让应用在尽量不中断服务的情况下重新读取自己的配置。

并非每个服务都实现 reload。若 unit 没有定义可用的重载方式，命令会失败。即使支持，应用也可能只重载部分设置，某些监听端口、用户或进程模型变化仍要求 restart。

重载后要验证应用报告的实际配置和日志，不能仅凭 systemctl reload 返回 0 断言所有配置已经生效。

systemctl restart做什么？

restart 会停止指定单元再启动。它适合应用不支持 reload、配置变更必须重新初始化，或进程需要完整重建的场景。

restart 可能造成短暂中断，也可能触发依赖、socket、挂载和资源清理行为。对有状态服务，要先核对优雅停止、连接排空、超时、数据刷盘和多实例滚动策略。

try-restart 只在单元已经运行时重启；reload-or-restart 优先 reload，不支持时 restart；try-reload-or-restart 又增加“未运行则不启动”的条件。自动化脚本应选择明确语义，避免无意启动原本停用的服务。

reload和restart怎么选？

先查看服务官方文档与 unit 定义。小范围、明确支持热加载的配置可以 reload；二进制升级、环境变量、用户身份、文件描述符限制或不支持热加载的设置通常需要 restart。

对关键服务，应先用配置检查命令验证语法，再执行 reload 或滚动 restart，并观察错误率和健康状态。不要把“零停机”建立在未经验证的 reload 假设上。

daemon-reload做什么？

systemctl daemon-reload 让 systemd 管理器重新加载 unit 文件，并重新运行生成器、重建整个依赖树。它作用于 systemd 对 unit 定义的认识，不是要求业务进程重读自身配置。

当新增或修改 /etc/systemd/system 下的 unit、drop-in，或者改变 systemd 需要解析的定义后，应执行 daemon-reload。许多编辑工具会提醒 unit 文件已在磁盘变化，需要重载管理器配置。

daemon-reload 本身不会自动重启受影响服务。新 ExecStart=、环境设置或资源限制要应用到已有进程，通常还需 restart；是否需要由具体变更决定。

daemon-reload和daemon-reexec有什么区别？

daemon-reload 重新读取 unit 配置；daemon-reexec 让 systemd 管理器重新执行自身，同时序列化并恢复管理器状态。后者主要用于调试、软件包升级或 systemd 自身需要重新执行的特殊场景，不应作为普通 unit 修改后的固定步骤。

日常修改 service 文件优先 daemon-reload。看到问题时反复 daemon-reexec 可能掩盖真正的 unit 语法、依赖或应用启动错误。

reset-failed做什么？

单元进入 failed 后，systemctl reset-failed name.service 会清除该 failed 状态。它还会重置与单元相关的启动速率限制计数器以及部分运行时计数，使后续启动不再因旧的限速状态立即被拒绝。

reset-failed 不修复配置、不启动服务，也不删除日志。正确顺序是先通过 status 和 journal 找到失败原因，修复后 reset-failed，再启动并验证。如果根因仍在，服务会再次失败并重新累积计数。

不带单元名执行可能影响所有单元的 failed 状态，生产排障中应尽量指定目标，保留其他故障证据。

reset-failed和restart有什么区别？

restart 尝试停止并重新启动；reset-failed 只重置状态与计数器。服务因 StartLimitBurst 被限制时，直接 restart 仍可能立即失败，此时需要先修根因，再按需要 reset-failed。

某些正常启动或经过足够时间也会使限速状态变化，但自动化不应依赖模糊等待。记录失败时间、计数规则和明确恢复动作更容易审计。

systemctl mask做什么？

mask 通常在配置目录创建指向 /dev/null 的链接，使 unit 无法被启动，包括手动 start 和依赖拉起。它比 disable 更强，适合明确禁止某服务在当前系统激活的场景。

mask 默认不一定停止已经运行的服务；要同时停止可使用 mask --now，但执行前必须确认业务影响。解除使用 unmask，随后是否 enable 或 start 仍需单独决定。

某些 unit 可能已经以文件形式存在于目标配置路径，mask 会因冲突失败。不要为了成功而直接删除未知 unit 文件，应先用 systemctl cat 和 systemctl show -p FragmentPath 查清来源。

mask和disable有什么区别？

disable 只是移除由安装信息建立的启动链接，服务仍可手动启动或被依赖激活；mask 则让 unit 加载到不可启动的状态。若目标只是“不随某个 target 自动启动”，用 disable；若要求“任何路径都不得启动”，才考虑 mask。

核心系统单元、登录、网络、存储或远程访问服务被误 mask 可能导致系统不可用。远程服务器操作前必须准备独立恢复通道和回滚命令。

修改unit文件后的正确流程

推荐流程是：

1. 使用 systemctl cat name.service 查看主文件和所有 drop-in 的合并来源。

2. 用 systemctl edit name.service 创建管理员覆盖，避免直接改软件包文件。

3. 使用 systemd-analyze verify 检查可静态发现的问题。

4. 执行 systemctl daemon-reload。

5. 根据变更选择 reload 或 restart。

6. 检查 status、journal、进程属性和业务健康。

7. 若失败，恢复 drop-in 或配置并再次 daemon-reload 与重启。

daemon-reload 成功只说明管理器完成重载，不代表 unit 一定无误或服务能够启动。

为什么改了service文件却没有生效？

常见原因包括未执行 daemon-reload、改错了 FragmentPath、存在优先级更高的 drop-in、只 reload 了应用但变更需要 restart、服务由模板实例启动，或者当前操作的是 user manager 而文件属于 system manager。

可以依次检查：

systemctl cat name.service
systemctl show name.service -p FragmentPath -p DropInPaths
systemctl status name.service
journalctl -u name.service -b

用户单元使用 systemctl --user，其 daemon-reload 也属于用户管理器，不能与系统级命令混用。

transient、runtime和persistent变更怎么区分？

--runtime 产生的 enable、mask 等配置通常写入运行时目录，重启后消失；不带该选项的持久配置写入 /etc/systemd/system 等持久位置。临时排障使用 runtime 可以降低遗留风险，但必须在报告中注明重启后不会保留。

瞬态 unit 由运行时 API 创建，也不等同于磁盘上的常规 service 文件。检查问题时同时查看 unit 的 LoadState、UnitFileState、FragmentPath 和 Transient 属性。

安全排障顺序

先用只读命令确认 active、enabled、failed 与 masked 状态，再查看合并后的 unit 和日志。修改前保存当前配置与关键命令输出；验证语法后 daemon-reload；采用最小影响的 reload 或滚动 restart；最后用业务探针验证，而不是只看绿色的 active。

对 SSH、网络、存储和防火墙相关单元，远程操作必须预留控制台或第二会话。不要批量 mask 或 stop 未解析依赖的系统单元。

常见误区

enable之后服务为什么还是inactive？

因为 enable 默认只建立未来的启动关系，不立即 start。需要现在运行时单独 start，或明确使用 enable --now。

daemon-reload会让应用重新读取配置吗？

不会。它让 systemd 重读 unit 定义。应用配置是否生效还取决于 reload 或 restart。

reload一定比restart安全吗？

不一定。服务不支持完整热加载时，reload 可能失败或只应用部分配置。应按服务文档和变更类型选择。

reset-failed能修复启动失败吗？

不能。它清除状态和限速计数，不会修复路径、权限、语法、依赖或程序错误。

masked服务可以被依赖自动拉起吗？

正常情况下不能，这正是 mask 比 disable 更强的原因。解除 mask 后仍需单独决定是否 enable 或 start。

结论

start 控制现在是否运行，enable 管理未来的安装依赖，reload 让应用重读配置，restart 重建运行实例，daemon-reload 让 systemd 重读 unit，reset-failed 清除失败与限速状态，mask 强制禁止启动。把“运行状态、开机关系、应用配置、unit 定义、失败记忆和启动许可”分开处理，才能避免一条命令看似成功、实际配置却没有生效。

参考来源

1. systemd upstream manual source, systemctl：https://raw.githubusercontent.com/systemd/systemd/main/man/systemctl.xml

2. systemd upstream manual source, systemd.unit：https://raw.githubusercontent.com/systemd/systemd/main/man/systemd.unit.xml

3. systemd upstream manual source, systemd.service：https://raw.githubusercontent.com/systemd/systemd/main/man/systemd.service.xml

4. systemd upstream manual source, systemd manager：https://raw.githubusercontent.com/systemd/systemd/main/man/systemd.xml