timeoutstartsec是systemd在服务启动阶段主动设限的机制，防止因脚本死循环等导致无限期挂起；它控制从启动指令发出到服务进入active或failed状态的时间上限，超时后发送sigterm/sigkill。
开机启动项超时被系统强制杀，通常不是“被杀”，而是服务启动卡住、超时失败后被 systemd 主动终止或放弃——这种行为容易被误认为是“被杀”，实际是启动流程的保护机制。排查重点不在找谁“动手”，而在定位哪个服务卡在启动阶段、为何卡住、以及如何让它不拖慢整个系统。
看哪些服务启动耗时最长
systemd 启动过程中，某个服务如果长时间处于 activating (start) 状态，会触发默认超时（通常是 90 秒），之后 systemd 会标记为 failed 并继续后续流程。这会导致该服务没起来，还可能拖慢整体启动速度。
- 运行 systemd-analyze blame，查看启动耗时 Top 20 的单元。重点关注耗时 >5s 的 .service 或 .mount 单元
- 对高耗时单元，执行 systemctl status 单元名，观察 Active 行是否为 activating (start)，并检查日志中是否有 timeout、connection refused、No route to host 等关键词
- 特别留意网络相关服务（如 NetworkManager-wait-online.service）、远程挂载（.mount）、NFS、LDAP、数据库连接类服务——它们极易因依赖未就绪而卡住
查服务卡住的真实原因
很多服务“启动慢”本质是等待外部条件，比如网络通了没、某个设备挂上了没、另一个服务 ready 了没。不能只看它自己，要看它的依赖和上下文。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 用 systemctl list-dependencies --reverse 单元名 查谁依赖它；用 systemctl list-dependencies 单元名 查它依赖谁。例如某服务依赖 network-online.target，但网络实际没连上，就会一直等
- 检查它是否配置了 After= 和 Wants=，是否合理。比如一个 Web 服务应 After=network-online.target，而不是仅 After=network.target
- 临时加调试：编辑服务文件（sudo systemctl edit 单元名），加入 Environment=SYSTEMD_LOG_LEVEL=debug，再重启看 journal 日志细节
确认是否真被 OOM Killer 杀掉
极少数情况下，启动阶段某个服务（尤其是 Java、Node.js 类）内存暴涨，确实会被内核 OOM Killer 终止。这不是 systemd 超时，而是内核级强制终止，日志特征明显。
- 运行 dmesg -T | grep -i "killed process" 或 dmesg -T | grep -i "Out of memory"
- 若输出中含进程名（如 java、python3）和 score 值，基本可确认是 OOM Killer 所为
- 再查该服务的 systemd 内存限制：systemctl show 单元名 | grep Memory。如果设了 MemoryLimit= 且值过小，也可能导致启动中被 cgroup kill
检查 /etc/fstab 挂载项是否拖累启动
这是最常被忽略却影响巨大的点。/etc/fstab 中一条指向不存在 NFS、断开 USB 盘或错误 UUID 的 auto 挂载项，会让 systemd 在启动时傻等 90 秒才失败。
- 运行 sudo findmnt -D 和 sudo blkid，逐行比对 /etc/fstab 中的 UUID 或设备路径是否真实存在且可访问
- 对非关键挂载，添加 nofail（允许失败不报错）或 x-systemd.automount（按需挂载，不阻塞启动）
- 对远程文件系统，必须加 _netdev，否则 systemd 可能在网络就绪前就尝试挂载，必然超时
