先查 systemctl status service-name 的末尾日志，重点关注“failed with result”或“process exited”，再用 journalctl -u service-name -n 50 查详细原因；配置修改后必须 daemon-reload 再 restart；enable 失败需确认 service 文件存在、权限正确、命名规范且含完整三段；停服务优先用 stop，禁用启动才用 mask。
查服务状态总显示 inactive (dead) 怎么办
服务没跑起来，但 systemctl status 又不报错，大概率是启动失败后自动退出了。别急着重试，先看真实退出原因。
- 用
systemctl status <code>service-name查最近一次启动的完整日志，重点看末尾几行（尤其是Failed with result或Process exited） - 如果日志太短，加
-n 50多翻点：journalctl -u <code>service-name-n 50 - 常见坑：配置文件里路径写错（比如
ExecStart指向不存在的二进制）、权限不足（User=指定的用户没权限读配置或写日志）、环境变量缺失（EnvironmentFile路径不对或文件里有语法错误）
systemctl restart 不生效？可能是依赖没 reload
改完配置文件（比如 /etc/systemd/system/nginx.service）后只 restart，新配置大概率不会加载——因为 systemd 还缓存着旧 unit 定义。
- 必须先执行
systemctl daemon-reload，让 systemd 重新解析所有 unit 文件 - 再
systemctl restart <code>service-name才真正用上新配置 - 漏掉
daemon-reload是高频失误，尤其在脚本里批量操作时；可合并成一行：systemctl daemon-reload && systemctl restart <code>service-name - 注意：修改的是
/lib/systemd/system/下的原始文件？那得先systemctl disable再enable才能覆盖 symlink，单纯daemon-reload不够
想开机自启但 systemctl enable 报 Failed to enable unit: Unit file xyz.service does not exist
不是命令输错了，是 systemd 根本没找到你的 service 文件。
- 确认文件存在且路径正确：
ls /etc/systemd/system/<code>xyz.service或/lib/systemd/system/<code>xyz.service - 检查文件权限：必须是 root 可读（
644最安全），不能是755或其他可执行权限 - 文件名必须以
.service结尾，且内容里至少要有[Unit]、[Service]、[Install]三段，缺[Install]会导致enable失败 - 如果 service 文件是软链接，确保目标路径存在且可访问；
systemctl不会自动解析 broken link
临时停服务用 stop 还是 mask？
stop 是暂停当前运行，mask 是彻底锁死——连 start 都拒绝，适合防误操作或调试依赖链。
- 只想暂时停：用
systemctl stop <code>service-name，之后start就能恢复 - 想彻底禁止启动（包括被其他服务依赖时自动拉起）：用
systemctl mask <code>service-name，它会创建指向/dev/null的 symlink - 误
mask了？用systemctl unmask <code>service-name解锁，然后daemon-reload生效 - 注意：
mask后status显示masked，不是inactive；别把它和disable混了——disable只影响开机自启，不影响手动start
systemd 的行为高度依赖 unit 文件的完整性，一个空格、一个等号位置错，都可能让服务静默失败。调试时别跳过 journalctl -u 和 systemctl cat，它们比猜快得多。
