服务启动超时但日志为空，主因是日志未刷盘、systemd未捕获或进程提前卡死；应优先检查Type配置是否匹配实际启动行为，再排查依赖、资源限制、SELinux及日志缓冲机制。
服务启动超时但日志为空，通常不是没日志，而是日志没刷出来、没写到 systemd 日志缓冲区，或者服务在 systemd 捕获日志前就卡死了。重点排查方向是服务启动流程卡点、依赖关系、资源限制和日志落盘机制。
检查服务实际启动状态和实时输出
systemd 超时（默认 90 秒）后会强制 kill 进程，可能连日志都来不及写。先用以下命令观察真实行为：
-
加 -f 实时跟踪启动过程：
sudo systemctl start your-service.service && sudo journalctl -u your-service.service -f，注意看启动瞬间的输出（哪怕只有一两行） -
启动后立刻查全部日志（含 boot 前）：
journalctl -u your-service.service --all --no-pager，--all 可显示被截断或未刷盘的日志 -
用 strace 直接跟踪进程系统调用（临时启用）：
sudo strace -f -e trace=execve,openat,write,connect -s 200 -o /tmp/your-service.strace /usr/bin/your-binary args...，看卡在哪一步（如 open 失败、connect 阻塞、write 写日志文件失败）
确认服务类型（Type=）是否匹配实际行为
这是最常见却被忽略的原因。如果 service 文件里写的是 Type=simple（默认），但你的程序启动后立刻 fork 子进程并退出父进程（比如很多 Python/Node.js 守护进程），systemd 会认为“启动完成”，然后立即去检查服务状态——而此时真正干活的子进程可能还没初始化完，90 秒后被判定为 timeout。
- 若程序自己 daemonize（双 fork），必须设为
Type=forking，并正确配置PIDFile= - 若程序不退出、前台运行（推荐方式），用
Type=simple或Type=notify（配合 sd_notify） - 检查当前配置：
systemctl cat your-service.service | grep Type=
排查依赖、资源与权限卡点
服务可能卡在等待外部条件，systemd 看不到，自然无日志：
-
依赖服务没起来：运行
systemctl list-dependencies --reverse your-service.service，再检查依赖项状态（如 network.target、redis.service、某个 mount 单元） -
文件系统挂载延迟：如果服务要读取 /data 或 NFS 目录，确认对应 mount unit 是否设置了
WantedBy=multi-user.target且已 active - 端口/文件锁冲突：手动执行服务命令（去掉 systemd 封装），看是否卡在 bind()、flock() 或 connect()
-
SELinux/AppArmor 静默拒绝：临时禁用测试：
sudo setenforce 0（CentOS/RHEL）或检查dmesg -T | grep -i avc
强制刷新日志并调整 systemd 启动参数
有些程序用缓存日志（如 log4j 的 async appender、golang 的 log.SetOutput 缓冲），或 stdout 没 flush 就卡住：
- 在 service 文件中加环境变量强制刷新：
Environment=PYTHONUNBUFFERED=1 NODE_OPTIONS=--no-warnings（针对 Python/Node） - 增加日志同步选项：
StandardOutput=journal+console和StandardError=journal+console，确保输出不丢 - 延长超时时间定位问题：
TimeoutStartSec=300（单位秒），改完记得sudo systemctl daemon-reload - 检查 journal 是否满或被轮转：
journalctl --disk-usage，必要时清理：journalctl --vacuum-size=100M
