Linux服务管理核心是systemd，需掌握单元文件配置、常用命令（如status/journalctl/list-dependencies/daemon-reload）、启停策略及日志依赖排查，通过MemoryLimit、After/Requires、ExecStartPre等实现生产级稳定。
Linux服务管理核心在于理解 systemd 机制、掌握常用命令、设置合理启停策略，并通过日志与依赖关系排查问题。稳定不是靠重启解决的，而是靠设计和监控。
systemd 是现代 Linux 服务管理的基石
从 SysV init 到 systemd，本质是把“脚本顺序执行”升级为“按依赖、状态、资源协同启动”。systemd 不只是启动服务，它统一管理服务（service）、套接字（socket）、定时器（timer）、挂载点（mount）等单元（unit）。每个服务对应一个 .service 文件，通常放在 /usr/lib/systemd/system/（系统自带）或 /etc/systemd/system/（管理员自定义）。
关键点：
- 服务文件中 WantedBy=multi-user.target 表示默认随系统启动；WantedBy=default.target 表示随图形界面启动
- Type= 决定 systemd 如何跟踪进程：simple（默认，启动后即认为就绪）、forking（传统 daemon，需指定 PIDFile）、notify（服务主动发通知，最可靠）
- Restart=on-failure 或 always 可让崩溃的服务自动拉起，但要配合 RestartSec=5 避免频繁闪退导致雪崩
日常服务操作必须掌握的命令组合
别只记 systemctl start/stop —— 真正排障靠的是状态联动与上下文观察：
- systemctl status nginx：看当前状态 + 最近 10 行日志 + 启动耗时 + CGroup 资源占用
- journalctl -u nginx -n 50 -f：实时跟踪服务日志（-n 指定行数，-f 类似 tail -f）
- systemctl list-dependencies --reverse nginx：查哪些服务依赖 nginx（比如反向代理后端挂了，前端可能卡在 waiting）
- systemctl daemon-reload：修改 .service 文件后必须执行，否则 reload/restart 不生效
让服务真正稳定：三类关键配置建议
默认配置往往只求能跑，生产环境需针对性加固：
- 内存与重启保护：在 service 文件中加 MemoryLimit=512M 和 RestartSec=10，防止 OOM 杀死后立即重试失败
- 启动顺序控制：用 After=network.target + Wants=network.target 确保网络就绪；若依赖数据库，写 After=postgresql.service + Requires=postgresql.service
- 健康检查兜底：搭配 ExecStartPre=/usr/bin/curl -f http://localhost:8080/health || exit 1，启动前探活，失败不继续
常见不稳定场景与快速定位思路
多数“服务莫名挂掉”其实有迹可循：
- 启动超时：systemd 默认 90 秒超时，服务初始化慢（如 Java 应用加载大量 bean）会直接 kill。加 TimeoutStartSec=300 并确认日志里是否有 “start operation timed out”
- 权限不足：服务以 nobody 用户运行却要写 /var/log/myapp/ —— 改用 User=myapp + 提前创建目录并 chown，或用 RuntimeDirectory=myapp 让 systemd 自动建 runtime 目录
- 日志被轮转清空：journalctl 默认只保留最近 1–2 周日志。如需长期留存，改 /etc/systemd/journald.conf 中 SystemMaxUse=1G 和 MaxRetentionSec=1month
基本上就这些。稳定不是一蹴而就的结果，而是对依赖、资源、生命周期持续校准的过程。多看 status，少盲目 restart；多配 RestartSec 和 MemoryLimit，少信“它自己会好”。
