90%的启动失败原因藏在journalctl -u 服务名 -n 50 -e的最后几行；需确认服务名正确、unit已加载且启用，journal持久化已配置，结合--no-pager与grep筛选错误，并用journalctl -b -p err追溯系统级根因。
直接看 journalctl -u 服务名 -n 50 -e，90% 的启动失败原因就藏在最后几行里。
journalctl -u 查不到日志？先确认服务名和 unit 文件是否加载成功
常见错误是输错服务名（比如 nginx.service 写成 nginx），或服务根本没安装、没启用。执行 systemctl list-units --type=service | grep 服务名 看是否出现在列表中；再用 systemctl status 服务名 确认 “Loaded” 行显示的路径是否存在、是否为 enabled。如果显示 not-found 或 masked，journalctl -u 就查不到任何内容——它只记录已加载 unit 的日志。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
为什么 journalctl -u 显示 “No entries”？检查 journal 是否持久化
默认情况下，systemd journal 只保存在内存或 /run/log/journal/（重启即丢）。若服务上次失败发生在上一次开机，而 journal 未配置持久化，journalctl -u 就会为空。此时应改用：journalctl -b -u 服务名（本次启动所有日志）
或先确认是否启用持久化：
- 检查 /etc/systemd/journald.conf 中 Storage= 是否为 persistent
- 若是 volatile，需手动创建目录并重启 journald：mkdir -p /var/log/journal && systemctl restart systemd-journald
日志里只看到 “Failed to start”，但没具体错误？加 --no-pager + grep -i
很多关键线索被分页器截断，或混在 INFO 级别日志里。不要只信 systemctl status 摘要。执行：journalctl -u 服务名 --no-pager | grep -i "fail\|error\|refused\|timeout\|denied"
特别注意以下模式：
- Permission denied：不是文件权限问题，很可能是 SELinux 上下文不对（ls -Z 看）或 systemd 的 ProtectHome=true 拦截了访问
- Address already in use：端口冲突，但 netstat -tulpn 可能看不到 socket-activated 服务，改用 ss -tlnp
- status=217/USER：unit 文件里 User=xxx 指定的用户不存在，或其 home 目录不可访问
- No such file or directory：常是 ExecStart 路径写错，或动态库缺失（ldd /path/to/binary 验证）
日志没报错，但服务就是不起来？试试 journalctl -b -p err
有些失败发生在依赖服务或系统级阶段，而非目标服务本身。比如：
- 网络未就绪导致服务因 DNS 查询超时失败（After=network-online.target 缺失）
- 时间未同步导致 TLS 握手失败（After=time-sync.target 未设）
- 根文件系统只读（df -h / 看是否显示 Read-only file system）
运行 journalctl -b -p err 查本次启动所有错误级别日志，往往第一处报错才是根因——它可能在你的服务启动之前就发生了。
真正卡住人的，往往是那些没出现在目标服务日志里的东西：环境变量缺失、工作目录不可写、EnvironmentFile= 路径不存在、甚至只是 $PATH 里没有 /usr/local/bin。别只盯着 journalctl -u，得顺着 systemctl show 服务名 输出的 Environment、WorkingDirectory、User 去手动复现 ExecStart 命令。
