用STM32 HAL库驱动OLED屏：从I2C初始化到图形显示的全流程代码解析
2026/4/26 0:20:46
想让程序开机就运行？这份Ubuntu脚本指南请收好
你有没有遇到过这样的情况：写好了一个监控脚本、一个数据采集服务，或者一个后台工具，每次重启系统后都要手动打开终端、切换目录、输入命令才能运行？反复操作不仅费时，还容易遗漏——尤其当这台机器要长期无人值守运行时，开机自动启动就成了刚需。
Ubuntu提供了多种让脚本随系统启动的方法，但网上资料常常混杂着过时方案、权限陷阱和实操坑点。有人试了rc.local却没生效，有人配了systemd service却卡在“inactive (dead)”状态，还有人用init.d脚本结果发现Ubuntu 20.04+默认已弃用SysV init。别担心，这篇指南不讲理论套话，只聚焦真实可运行、适配主流Ubuntu版本（18.04/20.04/22.04/24.04）、覆盖不同场景需求的三种可靠方案。每一种都经过本地环境反复验证，附带完整命令、关键注释和避坑提示，照着做就能跑通。
1. 推荐首选：systemd服务方式（现代、稳定、可控）
Ubuntu自16.04起全面转向systemd作为默认初始化系统，它比老旧的SysV init更健壮、支持依赖管理、状态监控和日志追踪。如果你的Ubuntu是20.04或更新版本，这是最值得优先尝试的方式。
1.1 创建服务单元文件
systemd通过.service文件定义服务行为。我们以一个实际例子说明：假设你的程序位于/home/ubuntu/myapp/start.sh，它需要在系统完全联网后启动，并持续运行。
首先，创建服务文件：
sudo nano /etc/systemd/system/myapp.service填入以下内容（注意替换路径和描述）：
[Unit] Description=My Custom Application Service After=network-online.target Wants=network-online.target [Service] Type=simple User=ubuntu WorkingDirectory=/home/ubuntu/myapp ExecStart=/home/ubuntu/myapp/start.sh Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target关键字段说明（用人话解释）：
After=network-online.target：确保网络完全就绪后再启动，避免因网络未通导致程序失败User=ubuntu：以普通用户ubuntu身份运行，不推荐用root，安全又够用Type=simple：适用于前台持续运行的脚本（如Python服务器、循环采集脚本）Restart=on-failure：如果脚本意外退出，systemd会自动重启它，提升可靠性StandardOutput=journal：所有打印输出会自动记录到系统日志，方便排查问题
1.2 启用并测试服务
保存文件后，刷新systemd配置并启用服务：
# 重新加载配置，让systemd识别新服务 sudo systemctl daemon-reload # 启用服务（设置为开机自启） sudo systemctl enable myapp.service # 立即启动服务（无需重启） sudo systemctl start myapp.service验证是否运行成功：
# 查看服务状态（重点关注Active: active (running)） sudo systemctl status myapp.service # 实时查看日志输出（按Ctrl+C退出） sudo journalctl -u myapp.service -f # 查看最近10条日志 sudo journalctl -u myapp.service -n 10如果看到Active: active (running)且日志中显示你的程序正常输出，说明已成功。下次重启系统，它会自动启动。
1.3 常见问题与解决
问题：服务启动失败，报错“Permission denied”
→ 检查start.sh是否有执行权限：chmod +x /home/ubuntu/myapp/start.sh问题：日志显示“Failed to start My Custom Application Service”
→ 先手动运行脚本：/home/ubuntu/myapp/start.sh，看是否报错。常见原因：路径错误、缺少依赖（如Python模块）、环境变量缺失。可在[Service]段添加Environment="PATH=/usr/local/bin:/usr/bin:/bin"问题：想让服务在图形界面登录后才启动？
→ 将WantedBy=multi-user.target改为WantedBy=default.target，并把User=设为当前登录用户，再用systemctl --user enable myapp.service启用（需配合loginctl enable-linger）
2. 兼容性最强：rc.local方式（适合快速验证）
虽然rc.local在新版Ubuntu中默认被禁用，但它依然有效且简单直接，特别适合临时测试、轻量级任务或需要兼容老系统的场景。它的核心逻辑就是：系统启动到最后阶段时，顺序执行这个脚本里的所有命令。
2.1 启用rc.local并编辑
Ubuntu 20.04+默认不启用rc.local，需先激活：
# 创建rc.local文件（如果不存在） sudo nano /etc/rc.local填入标准模板（务必保留#!/bin/bash和exit 0）：
#!/bin/bash # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # Your custom commands here # 示例：启动/home/ubuntu/myscript.sh su -c "/home/ubuntu/myscript.sh" -s /bin/bash ubuntu exit 0重要细节：
- 第一行必须是
#!/bin/bash（不是#!/bin/sh），否则可能不支持某些语法 - 所有命令必须放在
exit 0之前 - 如果脚本需要GUI环境（如调用浏览器），此方法不适用；若需用户权限，用
su -c "command" -s /bin/bash username切换用户执行 su -c比sudo更可靠，避免密码交互问题
2.2 设置权限并启用
# 添加执行权限 sudo chmod +x /etc/rc.local # 启用rc-local服务（Ubuntu 20.04+必需步骤） sudo systemctl enable rc-local # 检查状态（应显示active (exited)） sudo systemctl status rc-local重启系统即可验证。如果没生效，检查/var/log/syslog中是否有rc.local相关报错。
3. 传统但有效：SysV init脚本（仅限Ubuntu 18.04及更早）
如果你维护的是Ubuntu 18.04或更老的系统，或者需要与遗留系统保持一致，SysV init脚本仍是可行选择。不过请注意：Ubuntu 20.04+已移除对update-rc.d的默认支持，此方法不推荐用于新系统。
3.1 编写标准init脚本
创建脚本文件：
sudo nano /etc/init.d/myapp-init内容如下（严格遵循LSB头格式）：
#!/bin/bash ### BEGIN INIT INFO # Provides: myapp-init # Required-Start: $local_fs $network $syslog # Required-Stop: $local_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start myapp at boot time # Description: Enable service provided by myapp. ### END INIT INFO case "$1" in start) echo "Starting myapp..." su -c "/home/ubuntu/myapp/start.sh" -s /bin/bash ubuntu ;; stop) echo "Stopping myapp..." pkill -f "/home/ubuntu/myapp/start.sh" ;; restart) $0 stop $0 start ;; *) echo "Usage: /etc/init.d/myapp-init {start|stop|restart}" exit 1 ;; esac exit 03.2 安装并注册服务
# 添加执行权限 sudo chmod +x /etc/init.d/myapp-init # 注册到启动序列（Ubuntu 18.04） sudo update-rc.d myapp-init defaults # 立即启动 sudo service myapp-init start4. 方案对比与选型建议
面对三种方法，如何选择？下面这张表帮你快速决策：
| 维度 | systemd服务 | rc.local | SysV init脚本 |
|---|---|---|---|
| 适用Ubuntu版本 | 16.04+（推荐20.04+） | 所有版本（需手动启用） | 18.04及更早（20.04+不推荐） |
| 启动时机控制 | ★★★★★（可精确指定依赖） | ★★☆☆☆（固定在最后） | ★★★☆☆（依赖声明较弱） |
| 故障恢复能力 | ★★★★★（自动重启、日志追踪） | ★☆☆☆☆（失败即终止） | ★★☆☆☆（需自行实现） |
| 调试便利性 | ★★★★★（journalctl实时查日志） | ★★☆☆☆（需重定向输出到文件） | ★★☆☆☆（日志分散） |
| 上手难度 | ★★★☆☆（配置稍多但一次成型） | ★★★★★（改一行代码就能用） | ★★☆☆☆（LSB头易出错） |
| 安全性 | ★★★★★（可指定用户、工作目录） | ★★☆☆☆（默认root权限） | ★★☆☆☆（常需root） |
我们的建议：
- 新项目、生产环境、需要稳定性的场景 → 无条件选systemd。它解决了90%的运维痛点，学习成本远低于后期排障成本。
- 快速验证、临时任务、老系统维护 → 用rc.local。改完保存就能测，失败了删掉文件就行，零风险。
- 除非明确要求兼容Ubuntu 18.04以下系统 → 避免SysV。它的设计哲学已过时，systemd能更好替代。
5. 通用避坑指南（血泪经验总结）
无论选哪种方式，这些细节踩中一个就可能导致启动失败：
- 路径必须写绝对路径：
cd ~/myapp在开机脚本中无效，~不会被展开，一律用/home/ubuntu/myapp - 环境变量不继承：
.bashrc中的PATH、PYTHONPATH等在systemd或rc.local中不可用。解决方案：在脚本开头显式声明，如export PATH="/usr/local/bin:$PATH" - 守护进程需正确处理后台化：如果脚本本身会fork子进程（如
nohup python server.py &），systemd可能误判为主进程已退出。此时改用Type=forking并设置PIDFile=，或让主脚本前台运行（推荐） - GUI程序启动限制：
gnome-terminal、firefox等需要X11显示环境，在纯命令行启动时会失败。如需图形界面，应使用桌面环境的启动应用（如Startup Applications） - 权限宁小勿大：永远优先用普通用户运行，仅在必要时加
sudo。用root运行非必要服务是重大安全隐患
6. 总结：让自动化真正落地
开机自启不是炫技，而是让技术回归服务本质——把重复劳动交给系统，把注意力留给真正需要思考的问题。本文提供的三种方案，没有“最好”，只有“最适合”：systemd是面向未来的工程化选择，rc.local是手起刀落的效率利器，而SysV则是理解Linux演进的历史切片。
动手试试吧。从写一个简单的echo "Hello, system boot!" > /tmp/boot.log开始，验证流程是否通畅；再逐步替换成你的实际脚本。每一次成功的开机自启，都是对系统掌控力的一次确认。
记住，可靠的自动化不在于多酷炫，而在于：它默默运行，你几乎感觉不到它的存在——直到某天它没启动，你才发现它早已成为系统呼吸的一部分。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。