Linux服务管理核心在于理清服务归属、启动逻辑与配置生效机制：systemctl管systemd服务，service兼容旧脚本，自定义unit需配WantedBy和Type，修改后必须daemon-reload。
Linux服务管理其实不难，但新手常被 systemctl、service、chkconfig 这些命令绕晕，误以为“能启动就是服务配对了”，结果一重启全挂——核心问题往往出在单元文件没生效、目标（target）没对齐、或服务依赖没理清。
systemctl 不是万能钥匙，得看服务类型
不是所有服务都走 systemd。有些老脚本还在 /etc/init.d/ 下，用 service 命令调用；有些容器化服务（如 Docker 内的 Nginx）根本不在宿主机 systemd 管理范围内；还有些用户级服务（比如 user cron 或 gnome-keyring）得用 systemctl --user 才能管到。
- 查服务是否由 systemd 管理：运行 systemctl list-unit-files --type=service | grep your-service
- 看到 enabled/disabled 是指“开机是否启用”，不是“当前是否运行”
- 看到 static 表示该服务不能直接 enable，它只作为其他服务的依赖存在（比如 dbus.socket）
enable ≠ start，启动失败常因依赖未就绪
执行 sudo systemctl enable nginx 只是把软链接加到 /etc/systemd/system/multi-user.target.wants/，不启动进程；而 sudo systemctl start nginx 才真正拉起服务。但很多人 start 失败后直接重试，忽略日志提示。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 先看状态：systemctl status nginx（重点看 Active: failed 和下方的 “Process: … exited with code”）
- 查完整日志：journalctl -u nginx -n 50 -e（-n 50 是最近50行，-e 跳到底部）
- 常见坑：端口被占、配置文件语法错、SELinux 拦截、或依赖的 network-online.target 实际没就绪（尤其在云主机或 DHCP 环境）
自定义服务脚本，别漏掉 WantedBy 和 Type
写 .service 文件时，光有 ExecStart 不够。缺 WantedBy=multi-user.target，enable 就无效；Type 设错（比如该用 simple 却写了 forking），systemd 会等不到“就绪信号”，超时后 kill 进程。
- Type=simple：进程一启动就算服务就绪（推荐新服务默认用这个）
- Type=forking：适用于传统 daemon（如 httpd），需配合 PIDFile= 和 ExecStartPost=
- 务必加 Restart=on-failure 和 RestartSec=5，否则崩溃后不会自拉起
- 修改 unit 文件后，必须运行 sudo systemctl daemon-reload 才生效
别信“service xxx restart”万能，它可能只是兼容层
在较新发行版（如 Ubuntu 22.04+/CentOS 8+）中，service nginx restart 实际是调用 systemd 的 wrapper，行为和 systemctl 一致；但在某些最小化安装或容器里，service 命令可能根本不存在，或只认 /etc/init.d/ 脚本。
- 统一建议：新项目一律用 systemctl，避免混淆
- 检查 service 命令真实行为：type service 或 ls -l $(which service)
- 如果看到指向 /usr/bin/systemctl 的软链接，说明它是别名；如果是独立二进制或 shell 脚本，就得查它的实际逻辑
基本上就这些。理清“谁在管服务、何时算启动成功、改了怎么生效”，比死记命令重要得多。不复杂，但容易忽略细节。
