服务启动超时但日志空白，主因是systemd在90秒后强制kill进程导致日志未刷出，应优先检查type配置是否匹配实际启动行为（如type=simple与forking进程不兼容），再排查依赖、资源限制、selinux及日志缓冲机制。
服务启动超时但日志空白，往往不是没日志，而是日志根本没来得及输出——systemd 在 90 秒（默认）后直接 kill 进程，导致关键错误信息被截断。排查重点不在“找日志”，而在“定位卡点”。
先看真实启动过程，别只信 status
systemctl status 只显示快照，容易遗漏瞬时行为。真正有用的是启动瞬间的实时输出：
- 运行 sudo systemctl start your-service.service && sudo journalctl -u your-service.service -f，注意观察启动后头 1–2 秒是否有任何输出（哪怕只是 “Starting…”）
- 启动失败后立刻执行 journalctl -u your-service.service --all --no-pager，--all 能显示被截断、未刷盘或 boot 前的日志，常能捞出被忽略的关键行
- 如果服务启动极快又崩溃，用 strace 直接跟踪：sudo strace -f -e trace=execve,openat,write,connect -s 200 -o /tmp/svc.strace /usr/bin/your-binary args，看卡在 open 配置文件、connect 数据库，还是 write 日志失败
检查 Type= 配置是否与进程行为匹配
这是最常见却最容易被跳过的错误。systemd 根据 Type 判断“启动完成”的时机：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- Type=simple（默认）：认为 ExecStart 启动的进程就是主进程，它一退出，systemd 就认为服务已就绪——但很多 Python/Node.js 服务会 fork 子进程后父进程立刻退出，此时 systemd 误判启动成功，实际工作进程还在初始化，90 秒后超时
- Type=forking：适用于传统 daemon，要求进程明确 fork 并将子 PID 写入 PIDFile；若没写或路径错，systemd 找不到主进程，直接超时
- Type=notify：服务需调用 sd_notify(“READY=1”) 通知 systemd，否则永远等不到就绪信号
查依赖和资源限制，别让上游拖垮服务
服务本身没问题，但卡在等别人：
- 运行 systemctl list-dependencies --reverse your-service.service，看它依赖哪些 unit；再用 systemctl status 逐个检查这些依赖是否 active，尤其关注 network.target、remote-fs.target、cryptsetup.target 等易卡点
- 检查是否受资源限制：在 service 文件中查看是否有 MemoryLimit=、CPUQuota= 或 RestrictAddressFamilies=，过严的限制可能导致进程启动中途被 cgroup 杀死，且不留下明显日志
- SELinux 或 AppArmor 可能静默拦截系统调用（如 bind 端口、open 配置路径），临时设为 permissive 模式测试：sudo setenforce 0，再启动服务看是否还超时
验证日志落盘机制是否生效
有些服务用了缓冲日志（如 glibc 的 stdout 默认行缓冲），进程一挂，缓冲区内容就丢了：
- 在 ExecStart 命令前加 stdbuf -oL -eL 强制行缓冲，或启动时加 --log-level=debug 参数（如果支持）
- 确认服务是否尝试写入 /var/log/ 下的文件——而该目录所在文件系统可能未挂载或只读，journalctl 查不到，但 dmesg 里会有 “No space left on device” 或 “Operation not permitted”
- 检查 systemd-journald 状态：systemctl status systemd-journald，确保它没崩溃；journald 崩溃时新服务日志根本不会入库
