Linux 服务管理实战背景
在 Linux 系统中，服务管理是运维的核心能力之一，从早期的 SysV init 演进到现代的 systemd，带来了更高的可编排性、并发性和可观测性。
systemd 提供统一的单元模型，通过启动依赖、并发控制和统一日志实现，在大规模集群和容器场景中具备明显优势。
在日常运维中，掌握 systemd 相关工具（如 systemctl、journalctl）的使用，是提升故障定位与巡检效率的关键能力。
systemd 与 init 的核心差异
设计目标与启动模型
设计目标的差异直接决定启动行为：init 体系多采用顺序启动，随着脚本链的增多，系统启动时间呈线性增长。
systemd 使用依赖图驱动单元启动，通过并行启动和分组控制，显著缩短启动时间并提高稳定性。
单位类型与生命周期
传统 init 的单位类型较为单一，依赖以运行级别和脚本为核心，缺乏统一的生命周期管理。
systemd 引入了多种单位类型，如 service、socket、timer、mount 等，生命周期由 systemd 统一管理，包含激活、启动、停止、重启等状态。
诊断与日志机制
日志机制的整合性是 systemd 相比 init 的显著提升点，通过 journald 集中收集、存储与查询日志，提升可观测性。
与传统日志相比，系统日志的结构化、筛选与跨主机聚合能力更强，有助于快速定位启动失败与运行异常。
实操要点：在 Linux 环境中迁移与日常运维
从 SysV init 迁移到 systemd 的步骤
第一步通常是确认系统是否以 systemd 为进程 1，可以通过查看 /proc/1/comm 来判断。
SysV init 脚本的迁移目标是 unit 文件，systemd 会通过 systemd-sysv-generator 自动为 /etc/init.d 脚本生成兼容单元，但长期来看，应逐步编写原生 *.service 文件以获得最佳控制权。
# 检查 systemd 是否在运行
ps -p 1 -o comm=
# 查看当前已启用的服务
systemctl list-unit-files --type=service | grep enabled
随后为目标应用创建一个自定义的 unit 文件，并启用它：systemctl enable 与 systemctl start。
[Unit]
Description=我的应用服务
After=network.target[Service]
Type=simple
User=myuser
Group=mygroup
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/start.sh
ExecStop=/opt/myapp/bin/stop.sh
Restart=on-failure
RestartSec=5s[Install]
WantedBy=multi-user.target
创建完成后，应用单位将成为全局可用的服务，systemctl enable 将其设置为开机自启。
sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.service
常见系统诊断与日志查看
遇到服务启动失败时，优先检查 单位状态，以及最近的日志输出：
sudo systemctl status myapp.service
sudo journalctl -u myapp.service -b --no-pager
如果服务在开机过程中的依赖未就绪，journalctl 与 systemctl 的组合可以帮助定位依赖问题。
编写和管理自定义 unit 文件要点
在编写自定义单位时，Type 字段决定了启动方式，常见值包括 simple、forking、oneshot、notify、dbus，需结合应用行为选择。
[Service]
Type=forking
PIDFile=/var/run/myapp.pid
ExecStart=/usr/bin/myapp
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
此外，Restart 策略、Environment、After/WantedBy 等字段，直接影响容错和依赖链。
典型场景：从 SysV init 转向 systemd 的步骤和注意事项
从旧脚本到 unit 文件的迁移策略
对于大量旧脚本，逐步重写单元文件是稳妥的策略；系统会通过 systemd-sysv-generator 自动创建兼容单元，但长期来看，迁移为原生 unit才具备最好的并发与观测能力。
在迁移过程中，确保保留原有的启动脚本，以便回滚到稳定状态，记录每次变更的版本和效果，以便追溯。
兼容性与回滚策略
使用 systemd 的兼容性工具可以最小化切换风险：systemctl 可以管理旧脚本对应的单位，systemd-sysv-generator 负责在启动时将 SysV 脚本转化为单位。
为关键服务准备回滚路径，例如在新单元失败时能够快速切换回 SysV 脚本或镜像回滚。
调试与诊断工具：systemd 的日志与诊断
使用 journalctl
日志是定位问题的关键来源，journalctl 提供丰富的筛选能力，按时间、单位、优先级过滤日志。
# 查看最近 1 小时的系统日志
journalctl -b -1 -o short-precise
# 查看指定单元的日志
journalctl -u nginx.service --since "2 hours ago"
分析失败的单元
当一个单元无法启动时，systemctl show 与 systemctl status 提供关键的状态字段，帮助排查 启动失败、依赖丢失、资源不足 等原因。
systemctl status myservice.service
systemctl show myservice.service | sed -n '1,200p'
