systemctl disable没生效，是因为服务未被启用过、被mask、服务名错误或存在依赖单元（如.socket）；disable仅移除软链接且不影响当前运行，需用is-enabled、ls和list-unit-files三处验证。
systemctl disable 为什么没生效
执行 systemctl disable 服务名 后服务仍开机启动，大概率不是命令本身失败，而是你没确认它是否真被“启用”过。systemd 只对已启用（即存在软链接）的服务做 disable 操作；如果服务压根没被 enable 过，disable 会静默成功但无实际动作，systemctl is-enabled 服务名 返回 disabled 或 static 都说明它本来就不自启。
常见误判场景：
- 服务由其他单元（如
sshd.socket）触发启动，而非直接启用sshd.service - 服务被
mask过，此时disable不起作用，必须先unmask - 服务名输错，比如写成
nginx却实际单元文件叫nginx-mainline.service
systemctl disable 和 systemctl mask 的区别
disable 是移除软链接，服务仍可手动 start；mask 是把服务链接到 /dev/null，彻底堵死所有启动路径（包括依赖触发、手动 start），更彻底也更危险。
典型操作链：
- 想临时禁止某服务自启且保留手动启动能力 → 用
systemctl disable 服务名 - 想永久封禁某服务（比如测试环境禁用
bluetooth.service）→ 用systemctl mask 服务名 - 误 mask 后要恢复 → 必须先
systemctl unmask 服务名，再enable（如果需要）
验证 disable 是否真正完成
不能只看命令输出，得查三处：
-
systemctl is-enabled 服务名应返回disabled（不是static或masked） -
ls -l /etc/systemd/system/multi-user.target.wants/ | grep 服务名应无输出 -
systemctl list-unit-files --type=service | grep 服务名中对应行的 ENABLED 列应为disabled
注意：有些服务（如 systemd-timesyncd）默认是 static，它们没有 [Install] 段，天生不支持 enable/disable，强行 disable 会报错 “The unit files have no [Install] section.”
禁用后服务还在运行？这很合理
systemctl disable 只影响开机行为，完全不干预当前运行状态。所以 disable 后服务仍在跑是正常现象。如果你同时想停掉它，得加 --now：
sudo systemctl disable --now 服务名
这个命令等效于先后执行 disable 和 stop，但它是原子操作——如果 stop 失败，disable 也不会提交，避免系统处于半残状态。
容易忽略的一点：某些服务（如 docker）可能有多个关联单元（docker.socket、docker.service），只 disable 其中一个，另一个仍可能拉起它。务必用 systemctl list-dependencies --reverse 服务名 查清谁在依赖它。
