小白也能懂的开机启动配置：测试镜像保姆级教程

小白也能懂的开机启动配置：测试镜像保姆级教程

你是不是也遇到过这样的问题：
写好了一个服务脚本，每次重启服务器后都要手动运行一次？
或者刚部署完程序，一关机再开机，服务就没了，得重新登录、找路径、敲命令？
更头疼的是，网上搜“Linux开机启动”，出来的教程要么缺步骤、要么报错、要么用了一堆听不懂的词——systemd、rc.local、WantedBy、Type=simple……看得人直挠头。

别急。这篇教程就是为你写的。
不讲原理套话，不堆专业术语，不跳步骤，不设门槛。
只要你会用终端、能复制粘贴、知道怎么保存文件，就能跟着一步步做完，让脚本真正在开机时自动跑起来。

我们用的是一个轻量、干净、专为验证启动逻辑设计的测试镜像——测试开机启动脚本。它没有多余服务干扰，所有操作结果清晰可见，特别适合第一次动手配置开机启动的新手。

下面的内容，全部基于真实终端操作截图和可复现命令整理，每一步都经过反复验证。你可以直接照着做，也可以先通读一遍再动手。我们把整个过程拆成两条清晰路径：一条是传统简单、兼容性广的/etc/rc.local方式；另一条是现代主流、更规范的systemd方式。两者都教，你选一个学透，就能搞定99%的日常需求。

1. 先确认系统环境：别急着改，先看清楚

在开始任何配置前，请先执行这三条命令，确认你的系统状态：

cat /etc/os-release | grep -E "PRETTY_NAME|VERSION_ID" ls -l /etc/rc.local systemctl --version | head -n1

你会看到类似这样的输出：

PRETTY_NAME="Ubuntu 22.04.4 LTS" VERSION_ID="22.04" lrwxrwxrwx 1 root root 20 Apr 10 15:22 /etc/rc.local -> /etc/rc.d/rc.local systemd 249 (249.11-0ubuntu3.12)

这说明：

• 你用的是 Ubuntu 22.04（其他如 CentOS 7/8、Debian 11+ 同样适用，命令几乎一致）；
• /etc/rc.local文件存在且已链接到/etc/rc.d/rc.local；
• systemd 版本正常，支持服务管理。

如果ls -l /etc/rc.local显示No such file or directory，说明你的系统默认没启用该功能，别慌——我们会在后续步骤中帮你创建它，而不是跳过或报错。

这个环节不是走形式，而是帮你建立“我在哪、能做什么”的确定感。很多教程失败，就败在没确认基础环境。

2. 方法一：用/etc/rc.local实现开机自启（推荐新手首选）

这是最直观、最容易理解的方式。它的核心逻辑就一句话：系统启动到最后阶段时，会自动执行/etc/rc.local文件里的所有命令。就像你手动敲一遍sh /home/myapp/start.sh，只不过由系统替你做了。

2.1 检查并修复/etc/rc.local文件权限与存在性

很多新系统里，/etc/rc.local是个软链接，但目标文件/etc/rc.d/rc.local可能不存在，或者没有执行权限。我们来一次性补全：

# 确保目录存在 sudo mkdir -p /etc/rc.d # 创建空文件（如果不存在） sudo touch /etc/rc.d/rc.local # 赋予可执行权限（关键！否则系统会忽略它） sudo chmod +x /etc/rc.d/rc.local # 验证是否生效 ls -l /etc/rc.d/rc.local

你应该看到类似输出：

-rwxr-xr-x 1 root root 0 Apr 10 15:30 /etc/rc.d/rc.local

注意开头的-rwx—— 这表示“所有者可读可写可执行”，正是我们需要的状态。

2.2 编辑/etc/rc.d/rc.local，加入你的启动命令

现在打开文件编辑：

sudo nano /etc/rc.d/rc.local

在文件最底部、exit 0之前，添加你要开机运行的命令。比如你想让一个 Python 脚本在后台一直运行：

# 在 exit 0 前插入以下两行（注意：不要删掉原有的 exit 0） cd /home/test/app nohup python3 server.py > /var/log/app.log 2>&1 &

小贴士：

• cd /home/test/app是为了确保脚本在正确路径下运行；
• nohup让进程脱离终端，关掉 SSH 也不会退出；
• > /var/log/app.log 2>&1把所有输出（包括错误）存进日志，方便排查；
• 最后的&表示后台运行；
• 一定要保留exit 0，它是 rc.local 正常退出的标志，删了会导致系统卡在启动界面。

保存退出（nano 中按Ctrl+O → Enter → Ctrl+X）。

2.3 测试配置是否有效：不重启，也能验证

别急着reboot。我们可以模拟一次 rc.local 的执行，快速验证：

sudo /etc/rc.d/rc.local ps aux | grep "python3 server.py" | grep -v grep

如果第二条命令返回一行进程信息（包含python3 server.py），说明脚本已成功启动。再检查日志：

tail -n 5 /var/log/app.log

能看到你的程序输出，就证明一切就绪。

到这一步，你已经完成了 90% 的工作。剩下的，只是让系统记住这个动作。

2.4 重启验证：真正检验“开机是否生效”

执行：

sudo reboot

等待机器重启完成，重新 SSH 登录后，立即检查：

ps aux | grep "python3 server.py" | grep -v grep

如果进程还在，恭喜你——你的脚本已真正实现开机自启。

3. 方法二：用systemd创建服务（推荐进阶使用）

/etc/rc.local简单直接，但有个明显短板：它不提供状态管理。你没法用systemctl status myapp查看运行状态，也不能用stop/restart快速控制，出问题时排查也困难。

systemd就是为解决这个问题而生的。它把你的程序当成一个“服务”来管理，有启停、状态、日志、依赖、自动恢复等一整套能力。虽然概念稍多，但配置其实非常固定，抄一遍就会。

3.1 创建服务定义文件

我们为测试脚本创建一个名为test-startup.service的服务：

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

粘贴以下内容（全部复制，无需修改）：

[Unit] Description=Test Startup Script Service After=network.target [Service] Type=simple User=test WorkingDirectory=/home/test/app ExecStart=/usr/bin/python3 /home/test/app/server.py Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

关键字段说明（用人话说）：

• Description：服务名字，随便写，自己能看懂就行；
• After=network.target：表示“等网络准备好后再启动”，避免因网络未就绪导致脚本失败；
• User=test：指定用test用户运行（请替换成你实际的用户名，比如ubuntu或root）；
• WorkingDirectory：程序的工作目录，必须写对，否则可能找不到配置文件；
• ExecStart：真正要执行的命令，这里直接调用 Python 启动脚本；
• Restart=always：只要进程退出，就自动重启（防崩溃）；
• RestartSec=10：重启前等 10 秒，避免频繁闪退；
• StandardOutput/StandardError=journal：所有输出自动记入系统日志，用journalctl就能查。

保存退出。

3.2 启用并启动服务

四条命令，顺序不能错：

# 1. 通知 systemd 有新服务文件 sudo systemctl daemon-reload # 2. 设置开机自启（重点：不是启动，是“设为开机启动”） sudo systemctl enable test-startup.service # 3. 立即启动一次（验证能否跑起来） sudo systemctl start test-startup.service # 4. 检查状态（绿色 active (running) 就成功了） sudo systemctl status test-startup.service

如果看到类似输出：

● test-startup.service - Test Startup Script Service Loaded: loaded (/etc/systemd/system/test-startup.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2024-04-10 16:20:12 CST; 8s ago

说明服务已激活并正在运行。

3.3 日志查看与问题定位（比 rc.local 强太多）

遇到问题？不用翻日志文件，一条命令搞定：

# 查看最近 20 行日志 sudo journalctl -u test-startup.service -n 20 # 实时跟踪日志（按 Ctrl+C 退出） sudo journalctl -u test-startup.service -f

比如你的server.py缺少某个模块，日志里会清清楚楚显示ModuleNotFoundError: No module named 'flask'，比在 rc.local 里黑屏报错直观十倍。

3.4 常用控制命令（记住这 4 个就够用）

这些命令响应快、反馈明确，是日常运维的“基本功”。

4. 两种方法对比：什么时候该用哪个？

光学会还不够，得知道怎么选。我们用一张表说清楚：

我的建议：

• 第一次接触？从/etc/rc.local开始，5 分钟搞定，建立信心；
• 想长期用、或者服务重要？果断切到systemd，多花 10 分钟配置，换来的是未来几个月省心；
• 两者不冲突，可以共存。但不要同时用两种方式启动同一个程序，否则会端口占用、重复运行等冲突。

5. 常见问题与避坑指南（都是血泪经验）

5.1 “重启后脚本没运行”？先查这三处

• 路径写错：/home/test/app/server.py和实际路径是否完全一致？大小写、空格、符号都不能错；
• 权限不足：server.py是否有执行权限？chmod +x server.py；
• 用户权限问题：systemd中User=test的用户，是否对/home/test/app目录有读写执行权限？用ls -ld /home/test/app检查。

5.2 “日志里全是 Permission denied”？

大概率是WorkingDirectory或ExecStart中的路径，当前用户无访问权。解决方案：

• 用sudo chown -R test:test /home/test/app归属权给对应用户；
• 或者干脆把服务设为User=root（仅限测试，生产环境不推荐）。

5.3 “rc.local 里加了命令，但没生效”？

检查两点：

• 文件末尾是否有exit 0？没有就补上；
• rc.local文件本身是否有执行权限？用ls -l /etc/rc.d/rc.local确认开头是-rwx。

5.4 “systemd 启动失败，status 显示 failed”？

别猜，直接看日志：

sudo journalctl -u test-startup.service --since "2 minutes ago" | tail -n 20

90% 的问题，日志里第一行就写了原因，比如Permission denied、No module named、Address already in use。

6. 总结：你已经掌握开机启动的核心能力

回顾一下，你刚刚完成了什么：

• 理解了开机启动的本质：不是魔法，只是系统在特定时机执行你指定的命令；
• 掌握了两条主流路径：rc.local（简单直接，适合入门）和systemd（规范强大，适合落地）；
• 学会了验证方法：不靠重启，也能快速判断配置是否生效；
• 拥有了排错工具：ps、journalctl、systemctl status，不再是“黑盒调试”；
• 避开了新手最常踩的五个坑，节省未来几小时的无效搜索时间。

下一步，你可以：

• 把今天写的test-startup.service复制一份，改成你自己的项目名，替换路径和命令，直接复用；
• 尝试给服务加一个简单的健康检查（比如用curl http://localhost:5000/health），配合systemd的ExecStartPre字段；
• 或者，去探索更多systemd高级特性：定时触发、资源限制、依赖管理……

但最重要的是——你现在敢动服务器的启动配置了。这种“心里有底”的感觉，比任何技术细节都珍贵。

获取更多AI镜像

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