增加 Systemd 服务启动超时时间需要修改单元文件中的 TimeoutStartSec 参数。此方法适用于启动耗时较长的合法业务服务，风险在于可能掩盖服务启动失败的根本原因。
先说结论：通过 systemd 配置覆盖或编辑单元文件，将 TimeoutStartSec 设置为更大值或 infinity 可解决超时报错。
- 先确认：使用
systemctl status查看当前报错是否为 start operation timed out - 先处理：使用
systemctl edit创建覆盖配置，避免直接修改原始文件 - 再验证：执行
daemon-reload后重启服务，观察状态是否变为 active (running)
命令速用版
以下命令适用于大多数基于 systemd 的 Linux 发行版，直接替换 <service-name> 为实际服务名。
systemctl edit <service-name>
# 在编辑器中输入以下内容
[Service]
TimeoutStartSec=300
# 保存退出后执行
systemctl daemon-reload
systemctl restart <service-name>为什么会这样
Systemd 默认限制服务启动时间以防止进程挂起，超时后会自动杀死服务进程。
默认情况下，systemd 对服务启动等待时间有限制，通常默认值为 90 秒。如果服务初始化逻辑复杂、依赖网络加载或硬件就绪慢，容易触发 Operation timed out 错误。Systemd 认为服务启动失败，会发送 SIGTERM 信号终止该服务。
分步处理
按以下步骤修改超时配置，确保配置生效且可回滚。
- 检查当前状态：运行
systemctl status <service-name>，确认Result字段显示timeout。 - 创建覆盖配置：运行
systemctl edit <service-name>。此命令会创建/etc/systemd/system/<service-name>.service.d/override.conf文件，比直接修改原文件更安全。 - 写入超时参数：在编辑器中输入
[Service]段落，下方添加TimeoutStartSec=300。数值单位为秒，也可填infinity表示禁用超时。 - 重载配置：保存退出编辑器后，必须运行
systemctl daemon-reload，否则 systemd 不会读取新配置。 - 重启服务：运行
systemctl restart <service-name>应用更改。
怎么验证是否生效
通过服务状态和日志确认超时限制已放宽且服务正常启动。
- 状态检查：运行
systemctl is-active <service-name>，返回active表示成功。 - 日志检查：运行
journalctl -u <service-name> -n 20，确认没有Failed with result 'timeout'错误。 - 配置确认：运行
systemctl show <service-name> | grep TimeoutStartSec，查看显示的值是否为修改后的秒数。
常见坑
- 忘记重载守护进程：修改配置后未执行
daemon-reload，导致重启服务时仍使用旧配置。 - 配置段落错误：
TimeoutStartSec必须放在[Service]段落下，放在[Unit]或[Install]无效。 - 滥用 infinity：设置为
infinity可能导致故障服务无限挂起而不报错，建议优先设置具体秒数。 - 直接修改原文件：直接编辑
/lib/systemd/system/下的文件会在软件升级时被覆盖，应使用systemctl edit或编辑/etc/systemd/system/下的副本。
常见问题
Systemd 默认启动超时时间是多少？
默认通常是 90 秒，具体取决于 DefaultTimeoutStartSec 配置。
TimeoutStartSec 和 TimeoutStopSec 有什么区别？
前者限制启动等待时间，后者限制停止服务时的等待时间。
设置 infinity 会有副作用吗？
会导致服务启动卡住时 systemd 不主动杀死进程，可能占用系统资源。
参考来源
- freedesktop.org, systemd.service — Service unit configuration, https://www.freedesktop.org/software/systemd/man/systemd.service.html