Linux 服务启动超时的原因分析

systemd服务启动超时默认阈值为90秒，即TimeoutStartSec=90；可通过service文件配置该值或设为0禁用，修改后需执行systemctl daemon-reload生效。

systemd 服务启动超时的默认阈值是多少

systemd 默认对每个服务设置 TimeoutStartSec=90，即从 ExecStart 启动到进入 active (running) 状态，必须在 90 秒内完成，否则标记为失败并终止进程。这个值对数据库、java 应用、或带初始化逻辑的服务来说常常不够。

常见错误现象：systemctl status myapp.service 显示 failed，日志里有 Timed out waiting for process to start 或 Killed；journalctl -u myapp.service 最后几行往往停在启动命令输出之后、无后续状态变更。

• 可通过 systemctl show myapp.service | grep TimeoutStartSec 查看当前生效值
• 修改方式是在 service 文件中添加 TimeoutStartSec=300（单位秒），或设为 0 表示禁用超时（不推荐生产环境）
• 注意：修改后需运行 systemctl daemon-reload 才生效，否则 systemctl restart 不会读取新配置

服务卡在 pre-start 阶段的典型原因

很多服务依赖其他资源就绪才真正启动，比如等待网络接口 up、磁盘挂载完成、或另一个服务 ready。如果没显式声明依赖，systemd 可能并发启动，导致 ExecStart 运行时目标资源尚未可用，进程阻塞在 connect()、open() 或 init 脚本里 sleep 等待逻辑上。

典型表现是日志里没有 Started myapp.service，但能看到 Starting myapp.service... 后长时间无响应，ps aux | grep myapp 可能查不到进程，或只看到 shell 解释器卡在某条命令上。

• 检查 Wants= / After= 是否覆盖全部前置依赖，例如网络服务要加 After=network-online.target 并启用 systemctl enable systemd-networkd-wait-online.service
• 磁盘依赖应使用 RequiresMountsFor=/data 而非简单写 After=local-fs.target，后者不保证特定路径已挂载
• 避免在 ExecStartPre 中调用可能阻塞的命令（如未加 -w 的 curl、未设 timeout 的 nc），这类脚本超时也会触发整体启动失败

Java / python 类服务启动慢却不报错的陷阱

这类服务常通过 wrapper 脚本启动，ExecStart 启动的是一个 shell 进程，而真正业务进程 fork 在后台。systemd 默认按主进程生命周期判断服务状态，若主进程立即退出（比如脚本里用了 & 或 nohup），它会认为服务已“启动完成”，后续子进程崩溃也不会被感知；反之，若主进程一直不退出但也没发 readiness 信号，systemd 会在 TimeoutStartSec 后杀掉整个 cgroup。

常见错误配置：ExecStart=/opt/app/start.sh & —— 这会导致 systemd 认为主进程瞬间结束，状态变为 inactive，但实际 Java 进程还在跑；或者 ExecStart=java -jar app.jar 没加 Type=simple，而 jvm 启动耗时长，systemd 等不到它“ready”就超时。

• 推荐用 Type=simple（默认）配合前台运行的 Java 命令，确保 JVM 是主进程；若必须后台化，改用 Type=forking 并正确设置 PIDFile=
• Python flask/fastapi 服务建议加 gunicorn --preload 或用 waitress-serve，避免首次请求才加载模块拖慢启动
• 所有 wrapper 脚本务必去掉 set -e 外的静默错误处理，让失败直接暴露在 stdout/stderr，便于 journalctl 捕获

文件描述符、内存或 SElinux 导致的隐性超时

服务启动过程中若因资源不足无法分配 fd、mmap 失败，或被 SELinux 拦截 open/bind/connect，往往不会打出明确错误，而是卡在系统调用上，最终被 systemd 超时杀死。这类问题在容器外裸机部署时更隐蔽，因为 ulimit 和 SELinux 策略常被忽略。

典型线索：strace -p $(pidof myapp) 显示卡在 openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY|O_CLOEXEC) 或 connect(AF_INET, {...}, 16)；dmesg | tail 出现 avc: denied；cat /proc/$(pidof myapp)/limits 发现 Max open files 只有 1024。

• 在 service 文件中用 LimitNOFILE=65536 和 MemoryLimit=2G 显式限制并预留余量
• SELinux 下先临时设为 permissive 模式验证是否为此类问题：sudo setenforce 0，再重启服务；确认后用 ausearch -m avc -ts recent | audit2why 生成策略
• 避免在 ExecStartPre 中执行耗时的证书更新、密钥生成等操作，这些应由部署流程完成，而非每次启动都做

真正难排查的不是超时本身，而是那些不写日志、不返回错误码、只安静卡住的系统级阻塞——它们往往藏在 systemd 的 cgroup 边界之外，需要结合 strace、dmesg 和 /proc/*/stack 综合判断。