最可靠的方式是用 systemd 创建标准 .service 文件。它将服务纳入系统统一管理，支持启动顺序、权限控制、失败重启和日志追踪；文件须置于 /etc/systemd/system/ 下，包含 [unit]、[service]、[install] 三段，execstart= 必须用绝对路径，type= 需匹配脚本行为，after= 至少设 network.target，user= 显式指定，日志建议设为 journal；启用前须依次执行 daemon-reload、systemd-analyze verify、enable；脚本需适配 systemd 环境，命令用绝对路径，避免依赖 shell 环境变量；调试时可手动 start 并用 journalctl -u 查日志；其他方式如 rc.local 或 @reboot crontab 仅适用于临时或轻量任务。
最可靠的方式是用 systemd 创建标准 .service 文件。它不是简单“让脚本跑起来”，而是把你的服务纳入系统统一管理——能控制启动顺序、用户权限、失败重启、日志追踪，重启后也能稳稳拉起。
写一个合法的 .service 文件
文件必须放在 /etc/systemd/system/ 下，后缀为 .service，内容至少包含三段：[Unit]、[Service]、[Install]。
-
ExecStart= 后必须写绝对路径，比如
/usr/local/bin/myscript.sh，不能写myscript.sh或./myscript.sh -
Type= 要匹配脚本行为：
oneshot（执行完退出）、simple（常驻前台）、forking（传统后台 daemon） -
After= 至少加
network.target，避免网络没就绪就去连数据库或 API - User= 显式指定运行用户，别依赖 root；如果脚本要读取家目录，User 必须和该目录属主一致
-
StandardOutput= 和 StandardError= 建议设为
journal，否则日志全丢，查不到任何线索
启用前必须重载配置
systemctl enable 不会自动读取新文件或改动，它只建软链接。改完 .service 文件后，顺序不能错：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先运行
sudo systemctl daemon-reload - 再验证语法：
sudo systemd-analyze verify /etc/systemd/system/myapp.service，有报错就别往下走 - 最后执行
sudo systemctl enable myapp.service
脚本本身要适配 systemd 环境
终端里能跑 ≠ systemd 里能跑。systemd 启动时没有完整 $PATH、没有 tty、不继承 shell 环境变量。
- 脚本里所有命令都用绝对路径：
/bin/bash不用bash，/usr/bin/python3不用python3 - 如果依赖网络，别靠
sleep硬等，优先用After=+Wants=声明依赖 - 每次修改后，先手动试一次：
sudo systemctl start myapp.service，再看journalctl -u myapp.service输出，比等 reboot 验证快得多
其他可选方式（按推荐度降序）
如果只是临时调试或轻量任务，也可考虑：
-
/etc/rc.local：在
exit 0前添加命令，需确保文件有执行权限（chmod +x），systemd 系统还需启用rc-local服务 -
crontab @reboot：编辑
crontab -e，加一行@reboot /usr/bin/python3 /path/to/script.py >> /var/log/myapp.log 2>&1；注意路径全用绝对路径，且无法感知系统服务状态
