超详细图文教程：Ubuntu 18.04设置开机运行Shell

超详细图文教程：Ubuntu 18.04设置开机运行Shell

你是不是也遇到过这样的问题：在Ubuntu 18.04上写好了shell脚本，想让它开机自动运行，却发现/etc/rc.local文件根本不起作用？点开终端试了又试，重启后脚本还是没执行——别急，这不是你的操作错了，而是Ubuntu 18.04默认禁用了这个传统机制。

这背后的原因其实很清晰：Ubuntu 18.04全面转向systemd服务管理，而旧版的rc.local依赖于SysV init兼容层，系统默认不启用它。但好消息是，不用重装系统、不用换发行版、也不用学复杂的服务单元语法，只要6个清晰步骤，就能让rc.local重新工作，稳稳当当地帮你跑起自定义脚本。

本文全程基于真实环境验证（Ubuntu 18.04.6 LTS，内核5.4.0-150-generic），所有命令可直接复制粘贴，每一步都附带关键说明和避坑提示。无论你是刚接触Linux的新手，还是习惯用Ubuntu 14/16的老用户，都能照着做成功。

1. 为什么Ubuntu 18.04的rc.local不生效？

1.1 系统机制变化的本质

在Ubuntu 14.04及更早版本中，系统启动流程由SysV init控制，/etc/rc.local是标准的“兜底执行入口”——只要文件存在且有执行权限，它就会在多用户模式最后被调用。

而Ubuntu 18.04采用systemd作为默认init系统。systemd本身不原生支持rc.local，它需要一个“适配器服务”来桥接这个老机制。这个适配器就是rc-local.service，但它默认未安装、未启用、未激活。

关键理解：不是rc.local被删除或废弃了，而是它变成了一位“待岗员工”——得先给它发工牌（创建service文件）、签劳动合同（启用服务）、再打卡上班（启动服务），它才能干活。

1.2 常见误判与排查信号

如果你尝试过直接编辑/etc/rc.local却失败，大概率会看到以下现象：

• 手动执行sudo /etc/rc.local能成功，但重启后无任何效果
• systemctl status rc-local显示Unit rc-local.service could not be found
• /var/log/syslog里找不到rc.local相关日志
• ls -l /etc/rc.local显示权限为-rw-r--r--（缺少可执行位）

这些都不是脚本写错了，而是systemd层面的“准入机制”还没打通。接下来，我们就一步步把它建起来。

2. 创建rc-local.service服务单元

2.1 新建systemd服务配置文件

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

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

说明：路径/etc/systemd/system/是systemd用户级服务的标准存放位置，放在这里的服务能被systemctl直接识别和管理。

2.2 输入完整服务配置内容

将下方内容逐字复制进文件（注意大小写和空格）：

[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

逐项解析（小白友好版）：

• Description：服务的中文描述，便于你日后识别
• ConditionPathExists：告诉systemd——只有/etc/rc.local这个文件真实存在，才允许启动本服务
• Type=forking：声明这是一个“后台守护进程式”服务（传统rc.local的运行方式）
• ExecStart：真正要执行的命令——运行/etc/rc.local start
• TimeoutSec=0：禁止超时中断，避免脚本执行时间稍长就被杀掉
• RemainAfterExit=yes：关键！表示即使rc.local执行完了，也认为服务仍处于“活跃”状态，确保后续依赖它的服务能正常启动
• WantedBy=multi-user.target：定义服务启动时机——在系统进入标准多用户模式（即你日常使用的图形或命令行界面）时触发

保存并退出（vim中按Esc，输入:wq回车）。

3. 编写并配置/etc/rc.local脚本

3.1 创建rc.local主文件

执行命令新建文件：

sudo vim /etc/rc.local

3.2 填入标准模板并添加你的逻辑

将以下内容完整粘贴进去（请勿删除注释行，它们是systemd识别脚本合法性的依据）：

#!/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 "看到这行字，说明添加自启动脚本成功。" > /usr/local/test.log exit 0

重点说明：

• 第一行#!/bin/sh -e是必须的，它指定解释器为POSIX shell，并开启“出错即停”模式（-e）
• exit 0是强制要求——systemd把返回值0当作“执行成功”，否则会标记服务为失败
• echo ... > /usr/local/test.log是一行验证代码，用于确认脚本是否真被调用

保存退出。

3.3 设置可执行权限

sudo chmod +x /etc/rc.local

为什么必须加x权限？
systemd在启动服务时，会严格检查ExecStart指向的文件是否具备执行权限。没有x位，连第一步都迈不出去。

4. 启用并启动rc-local服务

4.1 启用服务（开机自启）

sudo systemctl enable rc-local

效果：该命令会在/etc/systemd/system/multi-user.target.wants/目录下创建一个指向rc-local.service的软链接。这意味着每次系统启动到多用户模式时，systemd都会自动加载并尝试启动它。

4.2 立即启动服务（无需重启）

sudo systemctl start rc-local.service

注意：命令末尾的.service可以省略，但显式写出更清晰，避免与其他同名unit混淆。

4.3 检查服务状态（关键验证步骤）

sudo systemctl status rc-local.service

成功状态应显示：

• Active: active (exited)或active (running)
• Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: enabled)
• 最后几行有类似Started /etc/rc.local Compatibility的日志

如果看到failed或inactive，请立即执行下一步排查。

5. 验证执行结果与常见问题排查

5.1 检查日志输出

cat /usr/local/test.log

预期输出：

看到这行字，说明添加自启动脚本成功。

出现这句话，证明rc.local已成功被systemd调用。

5.2 重启系统进行终极验证

sudo reboot

等待系统完全启动后，再次执行：

cat /usr/local/test.log

如果内容依然存在，恭喜你——基础环境已100%打通。

5.3 高频报错与解决方案

实用技巧：调试阶段，可在rc.local中加入时间戳日志，例如：
date >> /var/log/rclocal.log
这样每次启动都会记录时间，方便确认是否真的被执行。

6. 将rc.local作为“启动调度中心”（进阶用法）

现在你已经拥有了一个稳定可靠的启动入口。但直接在rc.local里写业务逻辑并不优雅——它更适合扮演“总指挥”的角色，把具体任务分发给独立的脚本文件。这样做有三大好处：
业务脚本与系统配置解耦，修改不影响核心机制
多个任务可并行或按需组织，结构更清晰
单个脚本出错不会导致整个启动链路中断

6.1 创建独立业务脚本（以Python为例）

假设你想开机自动运行一个Python程序ce.py，步骤如下：

第一步：创建Python脚本

sudo vim /home/ubuntu/ce.py

填入内容：

with open("/home/ubuntu/sb.txt", "w") as f: f.write("SB")

注意路径：务必使用绝对路径（如/home/ubuntu/sb.txt），因为开机时当前工作目录不确定。

第二步：创建调用它的Shell脚本

sudo vim /home/ubuntu/test.sh

填入内容：

#!/bin/bash cd /home/ubuntu/ python3 ce.py exit 0

关键点：

• 显式使用python3而非python（Ubuntu 18.04默认无python命令指向）
• cd切换到脚本所在目录，避免相对路径失效
• 末尾exit 0不可省略

第三步：赋予执行权限

sudo chmod +x /home/ubuntu/test.sh

6.2 修改rc.local调用外部脚本

编辑/etc/rc.local：

sudo vim /etc/rc.local

将原来的echo行替换为：

/home/ubuntu/test.sh exit 0

重要提醒：不要加sudo前缀！rc.local本身以root权限运行，加sudo反而会导致权限冲突。

保存后，重启验证——/home/ubuntu/sb.txt文件将如期生成。

7. 总结：一条安全、稳定、可维护的启动路径

回顾整个过程，我们没有改动系统底层，没有绕过systemd规范，而是尊重Ubuntu 18.04的设计哲学，用标准方式激活了一个被遗忘的经典机制。这套方案的价值在于：

• 零风险：所有操作仅新增配置文件，不影响现有服务
• 强兼容：未来升级到Ubuntu 20.04/22.04，此方法依然有效（已实测验证）
• 易维护：业务逻辑全部集中在/home/ubuntu/等用户目录，rc.local保持极简
• 好排查：每个环节都有明确的状态检查点（systemctl status、journalctl、日志文件）

你现在拥有的不仅是一个能开机运行的脚本，而是一套可扩展的自动化基础设施。无论是定时备份、服务监控、数据同步，还是AI模型常驻推理，都可以通过这个入口无缝接入。

下一步，你可以尝试：
🔹 把多个.sh脚本按顺序写入rc.local，实现启动流水线
🔹 结合systemd timer实现周期性任务，替代老旧的cron
🔹 为关键脚本添加健康检查，失败时自动告警

技术从来不是目的，而是让想法落地的杠杆。你已经握住了最稳妥的那一端。

获取更多AI镜像

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