5分钟搞定Ubuntu开机启动脚本，小白也能轻松上手

5分钟搞定Ubuntu开机启动脚本，小白也能轻松上手

你是不是也遇到过这样的问题：写好了Python脚本、部署好了服务，每次重启电脑却要手动运行一遍？眼睁睁看着自动化梦想在开机那一刻破灭……别急，今天这篇教程就是为你量身定制的。不需要懂systemd原理，不用查一堆文档，5分钟内，你就能让自己的脚本稳稳当当地在Ubuntu开机时自动跑起来——就像给程序装上“自动驾驶”，一开机就自己干活。

本文全程基于真实操作验证（Ubuntu 22.04/20.04均适用），所有命令可直接复制粘贴，每一步都附带说明和避坑提示。哪怕你第一次接触Linux，只要会用终端、能敲几行命令，就能搞定。我们不讲抽象概念，只说“怎么做”和“为什么这么写”。

1. 为什么老办法在新Ubuntu里失效了？

在Ubuntu 14.04时代，大家习惯往/etc/rc.local里加命令，系统启动时自动执行。但自Ubuntu 16.04起，systemd成为默认初始化系统，rc.local默认被禁用——不是它不能用，而是没人“叫醒”它。

你可以把rc.local想成一个待命的老员工：他能力没问题，但公司（systemd）没给他排班表，他就一直坐在工位上等通知。我们要做的，就是亲手为他创建一份正式的排班服务（.service文件），让他重新上岗。

注意：这不是“修复bug”，而是适配新系统的标准做法。Ubuntu官方明确支持通过rc-local.service启用rc.local，安全、稳定、无需改内核或降级。

2. 四步完成开机自启设置（实测有效）

整个过程只需四步，全部命令已按顺序整理好，建议边看边操作。每步耗时不超过1分钟，总计5分钟内可完成。

2.1 创建systemd服务文件：唤醒rc.local

打开终端，执行以下命令创建服务定义文件：

sudo nano /etc/systemd/system/rc-local.service

推荐用nano而非vim：对新手更友好，底部有操作提示（如^O保存、^X退出）

将以下内容完整复制粘贴进去（注意大小写和空格）：

[Unit] Description=/etc/rc.local Compatibility ConditionPathExists=/etc/rc.local [Service] Type=forking ExecStart=/etc/rc.local start TimeoutSec=0 StandardOutput=tty RemainAfterExit=yes SysVStartPriority=99 [Install] WantedBy=multi-user.target

关键点说明：

• ConditionPathExists确保只有/etc/rc.local存在时才启用该服务；
• RemainAfterExit=yes表示脚本执行完后服务仍视为“运行中”，避免systemd误判失败；
• WantedBy=multi-user.target对应图形界面和命令行共用的多用户启动目标，覆盖最广。

保存并退出（Ctrl+O→ 回车 →Ctrl+X）。

2.2 创建并编辑rc.local脚本：你的启动总控台

执行命令创建脚本文件：

sudo nano /etc/rc.local

粘贴以下基础模板（这是你未来所有自启任务的“入口”）：

#!/bin/sh -e # # 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. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. echo "开机自启服务已激活" > /var/log/rc-local.log # 在此处添加你的启动命令（见2.3节） exit 0

必须注意的两件事：

1. 第一行#!/bin/sh -e是固定写法，不可删改；
2. 最后一行exit 0是强制要求——缺了它，系统会认为脚本执行失败，导致服务启动中断。

保存退出。

2.3 添加你的实际任务：以Python脚本为例

假设你想开机自动运行/home/yourname/myscript.py，不要直接在rc.local里写python3 /home/...—— 这样容易因环境变量缺失而失败。

正确做法：封装成独立shell脚本，再由rc.local调用。

先创建专属启动脚本：

sudo nano /usr/local/bin/start-myapp.sh

写入内容（根据你的实际路径修改）：

#!/bin/bash # 切换到脚本所在目录（避免路径错误） cd /home/yourname/ # 激活虚拟环境（如有，取消下面这行注释并修改路径） # source /home/yourname/venv/bin/activate # 运行Python脚本 /usr/bin/python3 /home/yourname/myscript.py >> /var/log/myapp.log 2>&1

为什么这样写？

• 显式指定/usr/bin/python3避免PATH问题；
• >> /var/log/myapp.log 2>&1将输出和错误统一记录到日志，方便排查；
• 注释掉的虚拟环境激活行，按需开启。

赋予执行权限：

sudo chmod +x /usr/local/bin/start-myapp.sh

回到rc.local，在echo行下方、exit 0上方，添加调用命令：

# 启动我的应用 /usr/local/bin/start-myapp.sh

保存/etc/rc.local。

2.4 启用并验证服务：三行命令定乾坤

执行以下三条命令（顺序不可颠倒）：

# 1. 给rc.local执行权限（否则systemd拒绝运行） sudo chmod +x /etc/rc.local # 2. 启用服务（开机自动启动） sudo systemctl enable rc-local.service # 3. 立即启动服务（无需重启即可测试） sudo systemctl start rc-local.service

验证是否成功：

sudo systemctl status rc-local.service

看到类似输出即为成功：

● rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: enabled) Active: active (exited) since ...; 10s ago

如果显示failed，立刻执行sudo journalctl -u rc-local.service -n 20 --no-pager查看最后20行错误日志，90%的问题都能定位到具体哪一行出错。

3. 常见问题与避坑指南（血泪经验总结）

新手踩坑最多的地方，往往不是步骤错，而是细节疏忽。以下是实测高频问题及解决方案：

3.1 “脚本没运行，日志也没生成”——路径和权限双重检查

• ❌ 错误：rc.local中写的python myscript.py，但当前目录不是/home/yourname

• 解决：务必在启动脚本中用cd /path/to/script切换目录，或使用绝对路径调用

• ❌ 错误：myscript.py没有执行权限（Python脚本本身不需要，但shell脚本需要）

• 解决：确认start-myapp.sh已执行sudo chmod +x

3.2 “Python报错找不到模块”——环境变量丢失

systemd服务默认不加载用户shell配置（如.bashrc），因此pip install的包可能找不到。

两种可靠方案：

1. 显式指定Python解释器路径（推荐）：

   /usr/bin/python3 -m pip list | grep your-package # 先确认已安装 /usr/bin/python3 /home/yourname/myscript.py # 直接调用

2. 在shell脚本中手动加载环境：

   #!/bin/bash source /home/yourname/.bashrc # 加载用户环境 cd /home/yourname/ python3 myscript.py

3.3 “中文注释导致启动失败”——编码陷阱

Ubuntu默认UTF-8，但某些旧版系统或特殊终端下，rc.local若含中文注释，可能触发解析错误。

安全做法：

• rc.local和启动脚本中全部使用英文注释；
• Python脚本内中文无影响（源码文件声明# -*- coding: utf-8 -*-即可）。

3.4 “想同时启动多个脚本”——优雅管理方案

不要在rc.local里堆砌多行调用。推荐做法：

1. 创建统一管理脚本/usr/local/bin/start-all.sh；
2. 在其中按顺序调用各子脚本，并加入简单错误处理：

   #!/bin/bash /usr/local/bin/start-db.sh || echo "DB启动失败" >> /var/log/startup.log /usr/local/bin/start-web.sh || echo "Web启动失败" >> /var/log/startup.log

3. rc.local中只调用这一行：/usr/local/bin/start-all.sh

4. 进阶技巧：让自启更智能、更可控

掌握基础后，你可以进一步提升自动化体验：

4.1 延迟启动：避开资源争抢

某些服务依赖网络或磁盘挂载完成。若脚本过早运行，可能失败。

在rc-local.service的[Service]区块中添加：

ExecStartPre=/bin/sleep 10

表示启动前等待10秒，确保系统基础服务就绪。

4.2 日志集中管理：一眼看清运行状态

除了脚本内重定向日志，还可让systemd接管日志：

在rc-local.service的[Service]区块中添加：

StandardOutput=journal StandardError=journal

之后用sudo journalctl -u rc-local.service即可查看结构化日志。

4.3 条件启动：仅在特定硬件上运行

比如只想在服务器A上启动监控脚本，在笔记本B上跳过：

在rc.local开头添加判断：

# 仅在主机名为server-a时运行 if [ "$(hostname)" = "server-a" ]; then /usr/local/bin/start-monitor.sh fi

5. 总结：你已经掌握了Ubuntu自启的核心能力

回顾一下，你刚刚完成了：
理解了systemd下rc.local的工作逻辑；
创建了标准化的rc-local.service服务单元；
编写了可维护的启动脚本链（rc.local→start-xxx.sh→xxx.py）；
掌握了权限、路径、环境变量三大避坑要点；
学会了用systemctl status和journalctl快速诊断问题。

这不再是一个“临时凑合”的小技巧，而是一套可复用、可扩展、可交付的生产级启动方案。无论是个人项目、树莓派设备，还是小型服务器部署，这套方法都经得起考验。

下一步，你可以尝试：

• 把常用服务（如Node.js后台、Flask API）封装进启动流程；
• 结合cron实现定时+开机双保险；
• 用systemd timer替代简单延时，实现更精准的调度。

记住：自动化不是一蹴而就的魔法，而是由一个个像今天这样的“5分钟小胜利”累积而成。你现在，已经赢在了第一步。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。