面对 systemd 管理的服务过多导致启动慢，最稳妥的做法是先通过分析工具定位耗时单元，再逐一评估是否禁用非核心服务，避免直接批量关闭引发依赖故障。
先说结论：优化启动速度的核心在于减少不必要的并行等待和超时重试，而不是盲目禁用服务。
- 先定位：使用 systemd-analyze 找出耗时最长的单元
- 先做：确认服务用途后再执行 disable 或 mask
- 再验证：重启后对比分析数据并检查业务状态
命令速用版
# 查看整体启动耗时
systemd-analyze
# 列出按耗时排序的服务
systemd-analyze blame
# 查看关键链依赖
systemd-analyze critical-chain
# 检查失败的服务单元
systemctl list-units `--state`=failed为什么会这样
systemd 虽然支持并行启动，但服务之间存在依赖关系。如果某个非关键服务启动超时或卡在依赖检查上，会阻塞后续流程。此外，部分发行版默认启用了大量硬件检测或云初始化服务，在特定环境下（如无对应硬件）会等待超时后才继续，累积起来就表现为启动慢。
分步处理
1. 分析启动耗时
登录后直接运行 systemd-analyze blame，它会列出所有单元按启动时间排序。重点关注排在前面且时间异常长的服务。
2. 确认服务用途
不要直接禁用。使用 systemctl status 服务名 查看描述，或搜索该服务名称。例如 NetworkManager-wait-online.service 常因等待网络超时而耗时，若服务器使用静态 IP 且不需要等待网络完全就绪，可考虑调整。
3. 禁用或屏蔽服务
确认无用后，使用 systemctl disable 服务名 禁止开机启动。若该服务会被其他单元自动拉起，需使用 systemctl mask 服务名 彻底屏蔽。
恢复方法：若误操作需要恢复，使用 systemctl unmask 服务名 解除屏蔽，再执行 systemctl enable 服务名 恢复开机启动。
配置覆盖与超时调整
1. 安全编辑配置
不建议直接编辑 /usr/lib/systemd/system/ 下的原始 unit 文件，因为系统更新可能会覆盖修改。请使用 systemctl edit 创建覆盖配置：
systemctl edit 服务名该命令会打开编辑器，创建 /etc/systemd/system/服务名.d/override.conf 文件。
2. 调整超时参数示例
对于必须保留但启动慢的服务，可在覆盖配置中增加 TimeoutStartSec 避免默认超时等待。示例如下：
[Service]
TimeoutStartSec=30保存退出后，运行 systemctl daemon-reload 使配置生效。
怎么验证是否生效
重启服务器后，再次运行 systemd-analyze 对比总耗时。同时使用 systemctl list-units `--state`=failed 确认没有关键服务因优化操作而失败。业务端口监听和日志正常也是必要检查点。
常见坑
- 误禁网络服务：禁用 NetworkManager 或 systemd-networkd 可能导致远程失联，操作前确保有 console 权限。
- 依赖断裂：某些服务被禁用后，依赖它的业务服务会启动失败，需检查
systemctl list-dependencies。 - masking 不可逆：mask 会将服务链接到 /dev/null，恢复需执行 unmask，操作前建议记录变更。
- 直接编辑风险：直接修改原始 unit 文件会在系统包更新时丢失配置，务必使用 systemctl edit 进行覆盖。
参考来源
- freedesktop.org, systemd-analyze 手册页，https://www.freedesktop.org/software/systemd/man/systemd-analyze.html
- freedesktop.org, systemctl 手册页，https://www.freedesktop.org/software/systemd/man/systemctl.html
原文链接：https://www.zjcp.cc/ask/10898.html