Ubuntu设置开机运行脚本，就这么简单直接
在Ubuntu系统中，让一个脚本在每次开机时自动运行，其实并不需要复杂的配置或深奥的系统知识。很多新手一听到“开机启动”就想到修改rc.local、编辑crontab，甚至去研究init.d，结果绕了一大圈，发现要么不生效，要么权限出错，要么服务卡死。其实，现代Ubuntu（16.04及以后版本）默认使用systemd作为初始化系统，它提供了最稳定、最可控、也最符合标准的方式——写一个轻量级的.service文件。
这篇文章不讲历史沿革，不比对各种方法优劣，也不堆砌术语。我们就聚焦一件事：用最稳妥的方式，让你的脚本在Ubuntu开机后稳稳跑起来。整个过程只需5步，每一步都可验证、可回退、可复现，连刚装好系统的用户也能照着操作成功。
1. 明确你的脚本准备好了吗？
在设置开机启动前，请先确认你的脚本本身是可独立运行且无交互依赖的。这是最容易被忽略，却导致90%失败的根本原因。
1.1 脚本基础要求
- 有可执行权限：运行
chmod +x /path/to/your/script.sh - 首行指定解释器：如
#!/bin/bash或#!/usr/bin/env python3 - 路径全部使用绝对路径：不要写
./data.txt，要写/home/username/project/data.txt - 不依赖图形界面（除非你明确需要GUI）：开机早期阶段没有桌面环境，
DISPLAY变量未设置，调用notify-send或zenity会失败 - 避免阻塞式命令未处理：比如
ping -c 4 google.com是安全的，但tail -f /var/log/syslog会一直挂住，导致服务“启动中”卡死
1.2 一个真实可用的测试脚本示例
我们以镜像名称“测试开机启动脚本”对应的典型场景为例：一个用于记录启动时间并创建标记文件的简单脚本。
#!/bin/bash # 文件路径：/opt/scripts/boot-log.sh # 功能：每次开机写入当前时间到日志，并生成一个临时标记 LOG_FILE="/var/log/boot-time.log" MARKER_FILE="/tmp/system-started" echo "[$(date '+%Y-%m-%d %H:%M:%S')] System booted successfully" >> "$LOG_FILE" touch "$MARKER_FILE" chmod 644 "$LOG_FILE"保存后赋予执行权限：
sudo mkdir -p /opt/scripts sudo cp boot-log.sh /opt/scripts/ sudo chmod +x /opt/scripts/boot-log.sh提示：把脚本放在
/opt/或/usr/local/bin/这类系统级目录更规范，避免放在用户主目录下（如/home/xxx/），否则可能因用户未登录而无法访问。
2. 创建systemd服务文件（核心步骤）
systemd是 Ubuntu 的“管家”，它通过.service文件知道：这个脚本叫什么、谁来运行、什么时候启动、失败了怎么办。
2.1 新建服务文件
打开终端，用sudo nano创建服务定义文件（注意路径必须是/etc/systemd/system/）：
sudo nano /etc/systemd/system/boot-test.service注意：文件名必须以
.service结尾，且建议全小写、不含空格和特殊符号。
2.2 填写标准服务配置
将以下内容完整粘贴进去（请根据你的实际路径和需求修改）：
[Unit] Description=Test script for boot startup After=multi-user.target StartLimitIntervalSec=0 [Service] Type=oneshot ExecStart=/opt/scripts/boot-log.sh RemainAfterExit=yes User=root Group=root WorkingDirectory=/opt/scripts StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target2.3 配置项逐句解释（小白也能懂）
| 配置项 | 含义说明 | 为什么这么写 |
|---|---|---|
After=multi-user.target | 等系统基本服务（网络、磁盘、用户管理）就绪后再启动 | 避免脚本因网络未通或目录未挂载而失败 |
Type=oneshot | 表示这是一个“执行完就结束”的脚本，不是长期运行的守护进程 | 匹配我们这种一次性记录日志的场景，最常用也最安全 |
RemainAfterExit=yes | 即使脚本执行完了，systemd 仍认为服务处于“激活”状态 | 否则systemctl status会显示inactive (dead)，影响状态判断 |
User=root和Group=root | 以 root 权限运行（适合需要写系统日志、操作硬件等场景） | 若脚本只需普通用户权限，可改为User=yourname，更安全 |
WorkingDirectory | 指定脚本运行时的当前工作目录 | 防止脚本内相对路径（如./config.json）找不到文件 |
StandardOutput=journal | 所有echo、printf输出都会被记录到系统日志 | 方便后续用journalctl查看执行结果 |
小技巧：如果你的脚本需要等待网络完全就绪（比如要调用
curl请求远程API），可把After=改为After=network-online.target，并增加Wants=network-online.target。
3. 启用并验证服务
写完配置只是第一步，接下来要告诉 systemd：“这个服务我正式启用了”。
3.1 重新加载配置（必做！）
每次新建或修改.service文件后，都必须执行：
sudo systemctl daemon-reload这一步相当于“刷新缓存”，让 systemd 读取最新配置。漏掉它，后面所有操作都无效。
3.2 启用开机自启
sudo systemctl enable boot-test.service执行后你会看到类似提示：
Created symlink /etc/systemd/system/multi-user.target.wants/boot-test.service → /etc/systemd/system/boot-test.service.这意味着：下次开机时，systemd 会在进入multi-user.target（即命令行登录界面）前，自动拉起这个服务。
3.3 立即启动一次（手动触发测试）
sudo systemctl start boot-test.service3.4 检查是否成功运行
sudo systemctl status boot-test.service正常输出应包含：
Active: active (exited)（表示已成功执行完毕）Main PID:后面跟着一个数字，且状态为code=exited, status=0/SUCCESS
再检查日志内容是否写入：
sudo tail -n 3 /var/log/boot-time.log你应该能看到类似：
[2024-06-15 09:22:18] System booted successfully同时确认标记文件存在：
ls -l /tmp/system-started4. 常见问题与快速排查指南
即使严格按照上面步骤操作，也可能遇到“明明启用了，但开机没运行”的情况。别急，按顺序检查这四点，95%的问题都能定位。
4.1 日志是第一线索
永远优先看 journal 日志：
sudo journalctl -u boot-test.service -n 50 --no-pager- 如果看到
Permission denied→ 检查脚本权限和User设置 - 如果看到
No such file or directory→ 检查ExecStart=路径是否拼写错误，或脚本是否真在那个位置 - 如果看到
Failed at step EXEC spawning→ 很可能是解释器路径不对（比如写了#!/bin/sh但脚本用了[[ ]]语法）
4.2 检查服务是否真正启用
systemctl is-enabled boot-test.service返回enabled才正确；若返回disabled，说明enable命令没成功，重试一遍。
4.3 检查服务是否被其他单元屏蔽
极少数情况下，服务可能被意外屏蔽：
systemctl is-system-running # 应返回 "running"，不是 "degraded" 或 "maintenance" ls /etc/systemd/system/boot-test.service* # 确保没有出现 .service.d/ 或 .wants/ 下的冲突文件4.4 模拟开机环境测试（进阶但有效）
systemd 提供了一个命令，能模拟开机时的完整环境来运行服务，比单纯./script.sh更真实：
sudo systemd-run --scope --unit=test-boot-script /opt/scripts/boot-log.sh sudo journalctl -u test-boot-script -n 20 --no-pager如果这里能成功，但开机不行，大概率是After=依赖设置不合理。
5. 进阶建议：让脚本更健壮、更实用
完成基础功能只是开始。真正工程化部署时，还需要考虑这几件事：
5.1 添加超时保护（防卡死）
在[Service]段加入：
TimeoutStartSec=30表示如果脚本30秒内没执行完，systemd 会主动终止它，避免拖慢整个开机流程。
5.2 自动重试失败（适合网络依赖型脚本）
如果你的脚本需要联网（比如上传日志、拉取配置），可以加：
Restart=on-failure RestartSec=5 StartLimitIntervalSec=60 StartLimitBurst=3含义：失败后等5秒重试，1分钟内最多重试3次。
5.3 避免重复执行（幂等性设计）
有些脚本不能多次运行（比如初始化数据库）。可在脚本开头加锁判断：
LOCK_FILE="/var/run/boot-test.lock" if [ -f "$LOCK_FILE" ]; then exit 0 fi touch "$LOCK_FILE" # ... your main logic here ...或者更规范地用flock：
ExecStart=/usr/bin/flock -n /tmp/boot-test.lock -c "/opt/scripts/boot-log.sh"5.4 与系统服务联动（可选）
比如你想让脚本在nginx启动后再运行，只需改After=并加Wants=：
After=nginx.service Wants=nginx.servicesystemd 会自动确保依赖关系成立。
6. 总结：记住这五句话就够了
- 开机启动 ≠ 随便放个脚本：它必须满足可执行、路径绝对、无GUI依赖三大前提
- systemd 是现代Ubuntu唯一推荐方式：
rc.local已被弃用，cron @reboot不可靠，init.d过时 - 服务文件不是黑盒：
Type=oneshot+RemainAfterExit=yes是一次性脚本的黄金组合 - 验证三步走：
daemon-reload→enable→start+status，缺一不可 - 出问题先看 journal：
journalctl -u your-service-name是你最该记住的命令
现在，你已经掌握了 Ubuntu 下最干净、最标准、也最不容易翻车的开机脚本设置方法。不需要背命令，不需要记参数，只要理解“服务定义→启用→验证”这个闭环，就能举一反三，适配任何自定义脚本——无论是启动监控程序、初始化AI模型服务，还是每天自动备份数据。
下一步，你可以把这个方法套用到你的“测试开机启动脚本”镜像中，一键部署、开箱即用。
--- > **获取更多AI镜像** > > 想探索更多AI镜像和应用场景？访问 [CSDN星图镜像广场](https://ai.csdn.net/?utm_source=mirror_blog_end)，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。的模块化多电平换流器（MMC）整流电路仿真模型（Simulink仿真实现）)
