最常见原因是未加sudo导致权限不足，其次需检查服务是否运行、名称是否正确、单元文件是否存在、是否为static类型、重启策略及依赖关系，并区分stop与mask用途。
systemctl stop 服务名失败：权限和状态检查
没加 sudo 是最常见原因，普通用户无法操作系统级服务。另外，服务可能根本没运行，或者名字拼错了——systemctl list-units --type=service --state=running 能快速确认它是否在跑、真实名称是什么。
- 先用
systemctl status <code>服务名看当前状态，别凭印象猜名字（比如nginx实际可能是nginx.service） - 如果提示 “Unit
xxxnot found”，说明服务未安装或单元文件不在标准路径（/usr/lib/systemd/system/或/etc/systemd/system/） -
systemctl stop不会报错但也不起作用？大概率是服务被设为static类型，不能直接 stop，得查它的依赖关系或改用其他方式
服务停了又自动重启：检查 restart 策略和依赖项
有些服务被配置成崩溃后自启（Restart=always），或者被另一个服务依赖（比如 docker 依赖 containerd），你 stop docker，containerd 可能还在跑，甚至反过来拉起 docker。
- 用
systemctl show <code>服务名-p Restart 查重启策略，no才算真正“不自启” -
systemctl list-dependencies --reverse <code>服务名能看到谁依赖它；--all加上可显示隐式依赖 - 临时禁用自启：加
--now参数一起 disable，比如sudo systemctl disable --now <code>服务名
非 systemd 服务（比如直接 run 的脚本）怎么关
有些程序压根没注册进 systemd，而是通过 shell 启动的后台进程（比如 nohup python app.py &），systemctl 对它们完全无效。
- 用
ps aux | grep <code>关键词找进程 PID，再kill <code>PID或kill -9 <code>PID（慎用 -9） - 如果用了
screen或tmux，得先进入会话再退出，screen -ls和tmux ls先列出来 - 注意别只 kill 主进程却漏掉子进程，
pgrep -P <code>PID可查子进程，pkill -f <code>匹配字符串更省事
stop 和 mask 的区别：什么时候该用 mask
stop 是临时停止，mask 是彻底堵死——它会把服务名链接到 /dev/null，连手动 start 都会失败。适合那些你确定永远不用、又怕别人误启的服务（比如测试环境里关掉 firewalld）。
-
sudo systemctl mask <code>服务名后，start/enable全部报错：“Unitxxxis masked” - 解除用
unmask，但注意：mask 不影响已运行的实例，得先 stop 再 unmask - 别对关键系统服务（如
systemd-journald）随便 mask，可能导致日志丢失或诊断困难
真正麻烦的不是“怎么停”，而是停完之后有没有残留进程、有没有别的服务悄悄把它拉回来、以及那个“服务名”到底是不是你以为的那个东西——多看两眼 status 输出，比盲敲 stop 安全得多。
