开机启动脚本实操记录，附完整配置示例-程序员充电站

开机启动脚本实操记录，附完整配置示例

在实际项目部署中，经常需要让自定义脚本在系统启动时自动运行——比如初始化硬件、拉起监控服务、加载环境变量或启动AI推理服务。但很多开发者第一次配置时会遇到权限问题、路径错误、依赖未就绪等“看似简单却卡半天”的情况。本文不是照搬手册的理论复述，而是基于真实设备（Orange Pi、树莓派等ARM开发板）反复调试后整理出的一套可直接复制粘贴、一次生效的开机启动方案。

全文不讲抽象概念，只呈现：哪些步骤绝对不能跳过、哪些坑我踩过、哪些配置项必须改、哪些日志能快速定位问题。所有命令和配置都经过实测验证，适配主流Linux发行版（Ubuntu Server、Debian、Armbian等），核心逻辑基于systemd——这是当前最稳定、最可控、也最推荐的现代Linux服务管理方式。

1. 为什么不用rc.local？先说清前提

很多老教程仍推荐修改/etc/rc.local，但在较新版本的systemd系统中，它默认已被禁用或行为不可靠。原因很实际：

rc.local执行时机早于网络就绪，脚本里调用curl或连接数据库大概率失败
权限模型混乱，脚本以root身份运行但无法精确控制用户上下文
没有状态反馈机制，启动失败时静默退出，排查困难

而systemd服务天然支持：

依赖声明（如After=network.target确保网络可用后再启动）
用户隔离（明确指定运行用户，避免权限过高引发安全风险）
自动重启（Restart=on-failure让崩溃的服务自动恢复）
结构化日志（journalctl -u xxx.service精准查看每次启动的完整输出）

所以，除非你维护的是十年以上的嵌入式旧系统，否则请直接采用systemd方案。这不是“更高级”，而是“更省心”。

2. 四步完成配置：从创建到验证

整个流程严格按执行顺序组织，每一步都标注了必须检查的关键点。跳过任一检查项，都可能导致服务启动失败。

2.1 创建服务文件并写入配置

服务文件必须放在/etc/systemd/system/目录下，命名规则为xxx.service（建议用小写字母+短横线，避免空格和特殊字符）。我们以一个实际场景为例：启动一个名为startup-init.sh的初始化脚本，该脚本位于/opt/scripts/startup-init.sh，作用是设置GPIO引脚、启动摄像头服务并写入运行日志。

sudo nano /etc/systemd/system/startup-init.service

粘贴以下内容（注意：必须逐项核对替换）：

[Unit] Description=Run startup initialization script at boot After=network.target multi-user.target Wants=network.target [Service] Type=oneshot ExecStart=/bin/bash /opt/scripts/startup-init.sh RemainAfterExit=yes User=pi Group=pi WorkingDirectory=/opt/scripts Environment="PATH=/usr/local/bin:/usr/bin:/bin" StandardOutput=journal StandardError=journal SyslogIdentifier=startup-init [Install] WantedBy=multi-user.target

关键配置说明与必查项：

Type=oneshot：适用于执行完即退出的脚本（如初始化类）。若脚本需长期运行（如守护进程），应改为Type=simple并删除RemainAfterExit=yes
RemainAfterExit=yes：告诉systemd“脚本执行完不代表服务结束”，否则systemctl status会显示inactive (dead)，即使脚本已成功运行
User和Group：必须替换成你实际的用户名和组名（如pi、orangepi、ubuntu）。用whoami和groups命令确认
WorkingDirectory：显式指定工作目录，避免脚本内相对路径失效
Environment：显式声明PATH，防止systemd环境变量缺失导致命令找不到（如python3、curl）
StandardOutput/StandardError：强制日志输出到journal，便于后续排查

2.2 赋予脚本可执行权限并测试独立运行

systemd不会帮你解决脚本自身的权限问题。这一步常被忽略，却是90%启动失败的根源。

首先，确认脚本存在且路径正确：

ls -l /opt/scripts/startup-init.sh

如果提示No such file or directory，请先创建脚本。一个最小可用的测试脚本示例如下：

#!/bin/bash # /opt/scripts/startup-init.sh echo "$(date): Startup init started" >> /var/log/startup-init.log # 这里添加你的实际命令，例如： # echo "1" > /sys/class/gpio/export 2>/dev/null # echo "out" > /sys/class/gpio/gpio1/direction # /usr/bin/mjpg_streamer -i "/usr/lib/mjpg-streamer/input_uvc.so" -o "/usr/lib/mjpg-streamer/output_http.so -w /usr/share/mjpg-streamer/www" echo "$(date): Startup init completed" >> /var/log/startup-init.log

赋予执行权限：

sudo chmod +x /opt/scripts/startup-init.sh

手动执行测试（关键！）：

sudo -u pi /bin/bash /opt/scripts/startup-init.sh

检查/var/log/startup-init.log是否生成且内容正确
检查脚本内调用的命令（如mjpg_streamer）是否能在pi用户下正常运行
如果手动执行失败，systemd必定失败——先修复脚本本身

2.3 重载配置、启用并启动服务

完成上述两步后，才能进行systemd操作：

# 1. 通知systemd重新读取所有服务文件 sudo systemctl daemon-reload # 2. 启用服务（开机自启） sudo systemctl enable startup-init.service # 3. 立即启动服务（测试是否生效） sudo systemctl start startup-init.service

验证服务状态：

sudo systemctl status startup-init.service

健康状态的典型输出特征：

● startup-init.service - Run startup initialization script at boot Loaded: loaded (/etc/systemd/system/startup-init.service; enabled; vendor preset: enabled) Active: active (exited) since Mon 2024-05-20 10:30:15 CST; 2s ago Process: 1234 ExecStart=/bin/bash /opt/scripts/startup-init.sh (code=exited, status=0/SUCCESS) Main PID: 1234 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CGroup: /system.slice/startup-init.service

重点关注三处：

Loaded行显示enabled（已启用）
Active行显示active (exited)（正常退出）或active (running)（长期运行）
Process行显示status=0/SUCCESS（退出码为0）

若显示failed或inactive，立即进入下一步排查。

2.4 日志排查：精准定位失败原因

systemd日志是唯一可信的真相来源。不要猜，直接看：

# 查看最近10条日志（最常用） sudo journalctl -u startup-init.service -n 10 --no-pager # 查看本次启动的全部日志（含启动前后的上下文） sudo journalctl -u startup-init.service -b --no-pager # 实时跟踪日志（启动服务后运行，观察输出） sudo journalctl -u startup-init.service -f

高频问题与日志线索对照表：

日志中出现的关键字	可能原因	解决方法
`Permission denied`	脚本无执行权限，或`User`指定的用户无权访问脚本路径/调用命令	执行`sudo chmod +x`；检查`/opt/scripts/`目录权限（`sudo chown -R pi:pi /opt/scripts`）
`Command not found`	PATH环境变量缺失，或命令未安装在指定用户家目录	在`[Service]`段添加`Environment="PATH=..."`；用`which <command>`确认路径
`Failed at step EXEC spawning`	`ExecStart`路径错误，或脚本第一行`#!/bin/bash`缺失/错误	检查脚本路径拼写；用`file /opt/scripts/startup-init.sh`确认文件类型；确保首行是正确的shebang
`Unit network.target not found`	系统未启用network.target（极少见）	改用`After=multi-user.target`，或检查网络服务状态`systemctl status systemd-networkd`
`Timed out waiting for device`	脚本中访问了尚未就绪的硬件设备（如USB摄像头）	在`[Unit]`段添加`After=sys-devices-platform-soc-3f200000.serial-tty-ttyAMA0.device`等具体设备依赖，或增加`ExecStartPre=/bin/sleep 5`延时

3. 进阶技巧：让启动更健壮、更可控

生产环境往往需要更高可靠性。以下技巧均来自真实项目压测经验，非纸上谈兵。

3.1 添加启动延时与重试机制

某些硬件（如USB摄像头、串口设备）在系统启动初期可能未完全初始化。硬编码sleep虽简单，但systemd提供了更优雅的方案：

[Service] # 在执行主命令前等待5秒（比脚本内sleep更可靠） ExecStartPre=/bin/sleep 5 # 若首次启动失败，最多重试3次，每次间隔10秒 Restart=on-failure RestartSec=10 StartLimitInterval=60 StartLimitBurst=3

StartLimitInterval和StartLimitBurst组合可防止服务因持续失败而被systemd永久禁用。

3.2 限制资源使用，避免拖垮系统

开机脚本若失控（如无限循环），可能耗尽内存或CPU。通过cgroup限制：

[Service] # 限制最大内存使用为256MB MemoryMax=256M # 限制CPU使用率不超过50% CPUQuota=50% # 限制最大进程数为10 TasksMax=10

这些参数在资源受限的嵌入式设备上尤为重要。

3.3 优雅处理关机前清理

若脚本启动了后台进程（如mjpg_streamer），应在关机前终止它们。利用ExecStop：

[Service] # 启动时执行 ExecStart=/bin/bash /opt/scripts/startup-init.sh # 关机前执行（需脚本内实现pid保存与清理逻辑） ExecStop=/bin/bash -c 'if [ -f /var/run/startup-init.pid ]; then kill $(cat /var/run/startup-init.pid); rm /var/run/startup-init.pid; fi' # 确保关机时执行清理 RemainAfterExit=yes

对应地，脚本内需在启动后保存PID：

echo $! > /var/run/startup-init.pid

4. 常见误区与避坑指南

这些是社区提问中最高频的“我以为对，其实错”的点，务必警惕：

误区1：“脚本放在/home/pi/下就能用”
错。/home/pi/目录在用户登录前可能未挂载（尤其使用加密home分区时）。必须将脚本放在/opt/、/usr/local/bin/等系统级路径，并确保User有读取权限。
误区2：“systemctl enable后立刻生效”
错。enable只是创建软链接，必须执行daemon-reload才能让systemd识别新服务。漏掉此步是新手最常犯错误。
误区3：“日志看不到，一定是脚本没运行”
错。若StandardOutput未设为journal，输出会丢失。务必显式声明StandardOutput=journal StandardError=journal，这是调试的生命线。
误区4：“用root用户运行最省事”
错。权限过大易引发安全风险，且某些硬件访问（如GPIO）在root下反而受限。坚持最小权限原则，用普通用户运行，必要时通过gpio group等专用组授权。
误区5：“测试时systemctl start成功，重启后就失效”
错。大概率是enable未执行，或WantedBy目标错误。检查ls /etc/systemd/system/multi-user.target.wants/ | grep startup-init，确认软链接存在。

5. 总结：一份可复用的检查清单

最后，为你提炼一份开机启动脚本配置的终极检查清单。每次部署前，逐项打钩，可节省80%的排错时间：

[ ] 脚本文件存在且路径准确（ls -l /path/to/script.sh）
[ ] 脚本有可执行权限（sudo chmod +x /path/to/script.sh）
[ ] 脚本首行是正确shebang（#!/bin/bash）
[ ] 服务文件存于/etc/systemd/system/xxx.service
[ ] 服务文件中User和Group已替换为实际用户名/组名
[ ] 服务文件中ExecStart路径与脚本路径完全一致
[ ] 执行了sudo systemctl daemon-reload
[ ] 执行了sudo systemctl enable xxx.service
[ ] 执行了sudo systemctl start xxx.service
[ ]sudo systemctl status xxx.service显示active (exited)或active (running)且status=0/SUCCESS
[ ]sudo journalctl -u xxx.service -n 20日志中无Permission denied、Command not found等错误