服务启动超时但日志无记录，通常因 systemd 启动早期阶段 journald 尚未就绪或被禁用；需检查 journal 状态、unit 依赖与 timeout 配置、Type 类型匹配及启用 systemd 调试日志定位卡点。
服务启动超时但日志无记录，通常说明问题发生在 systemd 启动流程的早期阶段——还没来得及写入 /var/log/messages 或 journald 尚未就绪。排查需从 systemd 自身机制切入，而非只盯应用日志。
确认 journal 是否可用且包含服务启动上下文
/var/log/messages 是传统 syslog 的输出，而 systemd 服务默认由 journald 管理日志。若 journal 被禁用、配置为 volatile（内存存储）、或服务在 journal 初始化前崩溃，就会“查无记录”。
- 运行
journalctl -u your-service.service -n 100 --no-pager，不要依赖/var/log/messages - 检查 journal 状态：
journalctl --disk-usage（看是否为空）、systemctl is-active systemd-journald - 若 journal 未持久化，临时启用：
sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald
检查服务单元文件中的关键 timeout 和依赖配置
timeout 触发不等于服务失败，而是 systemd 主动终止了等待。常见原因不是服务本身卡住，而是它依赖的 target、设备或 socket 未就绪。
- 查看实际生效的 unit 配置：
systemctl cat your-service.service（注意 include 和 override） - 重点关注：
TimeoutStartSec=（默认 90s）、After=、Wants=、Requires=、BindsTo= - 特别留意是否依赖 network-online.target —— 它可能因 DHCP 超时或 NetworkManager 未响应而长期阻塞
- 用
systemctl list-dependencies --reverse your-service.service查谁等它，--all查完整依赖树
启用 systemd 启动调试并观察启动时序
让 systemd 输出更细粒度的启动行为，定位卡点在哪一步。
- 临时启用 debug 日志：启动时内核参数加
systemd.log_level=debug systemd.log_target=console（修改 grub 配置后sudo update-grub && reboot） - 或运行时动态提升日志级别：
sudo systemctl set-log-level debug，再sudo systemctl start your-service，立即journalctl -b -n 200滚动查看 - 关注关键词：
Starting ...→Started .../Failed to start .../Timed out waiting for .../Triggering OnFailure=...
验证服务进程是否真正 fork 与 daemonize 行为
如果服务是传统 SysV 风格守护进程（fork + exit parent），而 unit 文件未正确声明 Type=forking，systemd 会误判启动完成时机，导致假 timeout。
- 检查 unit 中
Type=值：simple（默认，主进程即服务进程）、forking（需明确指定 PIDFile=）、notify（需 sd_notify()）、oneshot等 - 用
strace -f -e trace=clone,execve,fork,vfork -p $(pgrep -f 'your-service')（启动中抓取）观察是否 fork 且父进程过早退出 - 若为 forking 类型，确保
PIDFile=存在且路径可读，且服务确实按预期写入该文件
不复杂但容易忽略：很多“没日志”的 case，本质是 journal 没开、unit 依赖写错、或 Type 配置和实际行为不匹配。先跳出应用日志，回到 systemd 的生命周期视角，链路就清晰了。
