自定义systemd服务文件绝大多数情况下应放在/etc/systemd/system/，文件名以.service结尾，权限设为644，编辑后需运行sudo systemctl daemon-reload。
systemd服务文件必须放在哪个目录
绝大多数情况下，自定义服务应放在 /etc/systemd/system/。这个目录是管理员手动管理服务的首选位置，优先级高于 /usr/lib/systemd/system/（后者属于软件包安装时写入，不建议直接修改）。
常见错误是把服务文件丢进 /lib/systemd/system/ 或随意建子目录——systemd 不会自动扫描子目录，也不推荐用 /lib 路径存放自定义配置。
- 服务文件名必须以
.service结尾，例如myapp.service - 文件权限建议设为
644（sudo chmod 644 /etc/systemd/system/myapp.service） - 编辑后必须运行
sudo systemctl daemon-reload，否则 systemd 完全读不到新文件或变更
ExecStart 启动命令写错的三种典型表现
ExecStart 是唯一必需的启动指令，但它不是 shell 命令行，不能直接写带管道、重定向或 && 的复合语句。写错最常导致服务卡在 activating (start) 状态，或秒退报 failed with result 'exit-code'。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 路径没写绝对路径：比如写
ExecStart=python app.py会失败，必须写ExecStart=/usr/bin/python3 /opt/myapp/app.py - 依赖环境变量没声明：Python 脚本用到 virtualenv，得加
Environment="PATH=/opt/myapp/venv/bin:/usr/local/bin:/usr/bin:/bin" - 前台进程没守住：脚本启动后立即返回（如漏了
--daemon=false或没加nohup ... & wait），systemd 会认为进程退出即服务结束；正确做法是让主进程保持前台运行，或用Type=simple+ 确保进程不 daemonize
为什么 start 没问题但 reboot 后不启动
根本原因通常是没启用服务，而只是写了服务文件。systemd 区分「存在服务」和「开机启用」两个状态，只放文件 ≠ 开机跑。
- 启用命令是
sudo systemctl enable myapp.service，它会在/etc/systemd/system/multi-user.target.wants/下建软链 - 禁用命令是
sudo systemctl disable myapp.service，仅删软链，不删原文件 - 验证是否启用：运行
systemctl is-enabled myapp.service，返回enabled才算到位 - 注意：如果服务设置了
WantedBy=graphical.target却运行在无桌面的服务器上，enable实际不会生效；普通后台服务统一用WantedBy=multi-user.target
调试自启动失败最有效的三步
别猜，直接看日志。systemd 把所有启动过程都记下来了，关键信息不在 /var/log/syslog，而在 journal。
- 查服务最后一次启动详情：
sudo journalctl -u myapp.service -n 50 --no-pager - 查 boot 后全部服务状态：
sudo systemctl status --all | grep myapp - 模拟开机流程测试：
sudo systemctl daemon-reload && sudo systemctl start myapp.service && sudo systemctl status myapp.service，这比重启快得多
特别注意 Active: 后面的状态 —— activating (start) 表示卡在 ExecStart；inactive (dead) 且没报错，大概率是进程自己退出了；failed 就一定得翻 journalctl。
