更稳妥、也更符合规范的做法，是直接使用 systemd 服务单元：在 /etc/systemd/system/myapp.service 里写好标准配置，把 After=network.target、User=pi、WorkingDirectory 和 ExecStart 这些关键项明确声明出来，而且都要使用绝对路径；同时补上 Restart=on-failure 与 Environment。配置完成后，再依次执行 daemon-reload、enable、start，最后通过 status 和 journalctl 检查运行状态并完成验证。
在 Debian 服务器上，如果要把服务配置成开机自动启动，更稳妥也更规范的做法，就是使用 systemd 服务单元。这套方式很适合各类需要长期后台运行的程序，比如 Web 服务、监控脚本，或者 AOT 编译后的 Linux ARM64 程序。它不仅能处理依赖关系，还支持自动重启和日志追踪，因此在 Debian 10+，尤其是 Debian 12/13 中，一直都是默认且更推荐的方案。
写一个标准的 .service 文件
在 /etc/systemd/system/ 下新建服务文件，例如 myapp.service：
- 用绝对路径：所有路径（
WorkingDirectory、ExecStart）必须写全，不能用~或相对路径 - 指定运行用户：避免用
root，建议设为普通用户（如User=pi或User=www-data） - 声明依赖：常用
After=network.target表示等网络就绪后再启动 - 设置重启策略：如
Restart=on-failure或Restart=always，配合RestartSec=5可加延迟
示例内容：
[Unit] Description=My AOT Application After=network.target [Service] Type=simple User=pi WorkingDirectory=/home/pi/myapp ExecStart=/home/pi/myapp/myapp-linux-arm64 Restart=on-failure RestartSec=5 Environment="PATH=/usr/local/bin:/usr/bin:/bin" [Install] WantedBy=multi-user.target
启用并验证服务
保存后执行三步命令：
sudo systemctl daemon-reload—— 重载配置（每次改完 .service 文件都必须执行）sudo systemctl enable myapp.service—— 启用开机自启（创建软链接到/etc/systemd/system/multi-user.target.wants/）sudo systemctl start myapp.service—— 立即启动，测试是否能跑起来
检查状态：
sudo systemctl status myapp.service—— 看是否 active (running)，有无报错sudo journalctl -u myapp.service -n 20 -f—— 查最后 20 行实时日志，定位启动失败原因（比如权限、路径、缺失库）
常见坑和绕过方法
如果服务启动失败，优先排查以下几类问题：
- 换行符错误：Windows 编辑的 .service 文件含
rn，systemd 会解析失败。用sed -i 's/r$//' /etc/systemd/system/myapp.service清理 - 权限不足：确保
ExecStart指向的二进制或脚本有+x权限（chmod +x /path/to/myapp） - 环境变量缺失：systemd 默认环境精简，需显式用
Environment=补充（如LD_LIBRARY_PATH、HOME） - 依赖未就绪：若程序依赖数据库或 Redis，可在
[Unit]加Wants=postgresql.service和After=postgresql.service
替代方案（仅限简单场景）
不推荐用于生产服务，但适合临时调试或极简需求：
- /etc/rc.local：需先启用该服务（
sudo systemctl enable rc-local），再编辑/etc/rc.local，在exit 0前加入启动命令（注意加&后台运行，并检查文件可执行权限） - 传统 init.d 脚本：Debian 已逐步弃用，仅兼容旧系统；需写完整 start/stop/restart 函数，再用
sudo update-rc.d myscript defaults注册
