告别手动运行！用开机启动脚本提升效率（附完整步骤）

告别手动运行！用开机启动脚本提升效率（附完整步骤）

你是否也经历过这样的场景：每天早上打开电脑，第一件事就是切到终端，cd进项目目录，敲下./bin/mywork，再等它慢慢启动？重复操作一周、一个月、一年……时间就悄悄溜走了。更糟的是，某天忘记手动运行，整个工作流就卡在起点。

其实，Linux系统早已为你准备好了“自动唤醒”能力——开机启动脚本。它不依赖图形界面，不挑环境，只要系统一通电、内核一加载、服务一就绪，你的核心任务就能静默启动、稳定运行。这不是高级运维的专利，而是每个开发者都能掌握的提效基本功。

本文聚焦一个真实可用、经过验证的实践路径：基于Ubuntu系统的开机启动脚本部署全流程。不讲抽象原理，不堆冗余选项，只呈现一条清晰、可复现、零踩坑的落地路线。所有步骤均已在标准Ubuntu 22.04环境实测通过，脚本可直接复制、修改、部署。

1. 明确目标与适用前提

在动手前，请先确认你的使用场景是否匹配这套方案：

• 你使用的是Ubuntu桌面版或服务器版（20.04/22.04）
• 你需要启动的是命令行程序、后台服务或自定义Shell脚本（如数据采集器、API网关、定时监控工具）
• 该程序不需要用户登录后才运行（即希望系统启动后、无人值守状态下即可工作）
• 你拥有sudo权限，能编辑系统级目录（/etc/init.d/、/etc/rc.local）

注意：本文方法不适用于需要GUI界面交互的程序（如弹窗提示、图形化操作），也不推荐用于需严格权限隔离的生产核心服务（这类场景建议改用systemd服务单元）。它最适合的是：你写的那个每天都要手动跑一次的“小而关键”的自动化脚本。

2. 推荐方案：创建独立init.d启动脚本（亲测最稳）

这是目前在Ubuntu上兼容性最好、稳定性最高、调试最直观的方式。它利用系统传统的SysV init机制，被update-rc.d工具管理，启动顺序可控，日志清晰，出问题时也容易定位。

2.1 编写可执行的启动脚本

我们以一个典型场景为例：你的程序位于/home/ubuntu/trx/bin/mywork，需要root权限运行，且依赖网络就绪。

首先，在家目录创建脚本文件：

cd ~ nano run.sh

将以下内容完整粘贴进去（注释不可省略，这是init.d识别脚本元信息的关键）：

#!/bin/sh ### BEGIN INIT INFO # Provides: run.sh # Required-start: $local_fs $remote_fs $network $syslog # Required-Stop: $local_fs $remote_fs $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Starts mywork daemon # Description: Starts the /home/ubuntu/trx/bin/mywork service ### END INIT INFO # 任务主体开始 case "$1" in start) echo "Starting mywork..." # 切换到程序所在目录 cd /home/ubuntu/trx # 使用sudo执行（注意：此处不建议硬编码密码，见下方安全说明） sudo -u ubuntu ./bin/mywork > /var/log/mywork.log 2>&1 & ;; stop) echo "Stopping mywork..." pkill -f "/home/ubuntu/trx/bin/mywork" ;; restart) $0 stop sleep 2 $0 start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 ;; esac exit 0

关键点说明：

• sudo -u ubuntu：以普通用户ubuntu身份运行，比直接用root更安全（避免程序意外获得过高权限）
• > /var/log/mywork.log 2>&1 &：将输出重定向到日志文件，并以后台方式运行（&）
• pkill -f：根据完整命令行字符串精准终止进程，比killall更可靠
• case结构：让脚本支持start/stop/restart命令，方便日常调试

安全提醒：原始参考中使用echo 123456|sudo -S ls的方式存在严重安全隐患（密码明文暴露、易被进程列表捕获）。本文已改为sudo -u ubuntu，前提是确保ubuntu用户对/home/ubuntu/trx/bin/mywork有执行权限。如确需root权限，请配置sudoers免密：sudo visudo，添加一行ubuntu ALL=(ALL) NOPASSWD: /home/ubuntu/trx/bin/mywork

2.2 将脚本放入系统服务目录并授权

保存退出后，执行以下命令：

# 复制到系统服务目录 sudo cp ~/run.sh /etc/init.d/run.sh # 赋予可执行权限 sudo chmod 755 /etc/init.d/run.sh

2.3 注册为开机启动服务

这一步是核心，它告诉系统：“这个脚本应该在哪个运行级别启动，优先级多少”。

# 注册服务（96为启动优先级，数字越大越晚启动） sudo update-rc.d run.sh defaults 96

为什么选96？
Ubuntu启动过程中，网络服务（networking）默认优先级为90，SSH服务为91。设为96，确保你的程序在网络就绪、SSH可用之后再启动，避免因网络未通导致连接失败。

2.4 验证与调试

注册完成后，无需重启即可测试：

# 手动启动服务 sudo service run.sh start # 查看是否运行 ps aux | grep mywork # 查看日志（确认输出是否正常） tail -f /var/log/mywork.log # 手动停止 sudo service run.sh stop

一切正常后，执行最终验证：

sudo reboot

重启后，等待约1分钟，执行：

ps aux | grep mywork

如果看到你的mywork进程正在运行，恭喜，你已成功实现全自动启动。

3. 备选方案：rc.local（适合极简需求）

如果你的程序非常轻量，且完全不需要复杂的启停逻辑，/etc/rc.local是最简单的选择。它本质是一个“万能钩子”，在系统初始化末尾、所有服务启动完毕后执行。

3.1 编辑rc.local文件

sudo nano /etc/rc.local

在exit 0这一行之前，插入你的启动命令：

# 启动mywork（确保脚本有执行权限） su -c "/home/ubuntu/trx/bin/mywork > /var/log/mywork.log 2>&1 &" -s /bin/sh ubuntu

注意：

• 必须以su -c切换到普通用户执行，避免root权限风险
• exit 0必须保留，且必须是文件最后一行
• 保存后赋予执行权限：sudo chmod +x /etc/rc.local

3.2 验证rc.local是否启用

Ubuntu 18.04+默认可能禁用rc.local。检查状态：

sudo systemctl status rc-local

若显示inactive，需启用：

sudo systemctl enable rc-local sudo systemctl start rc-local

然后同样通过sudo reboot验证。

4. 常见问题与解决方案

即使按步骤操作，也可能遇到意料之外的情况。以下是高频问题及应对策略：

4.1 脚本启动了，但程序很快退出

原因：程序本身是前台运行、执行完即退出；或缺少环境变量（如PATH、HOME）。

解决：

• 在脚本中显式设置环境：export PATH="/usr/local/bin:/usr/bin:/bin"
• 确保程序以守护进程方式运行（加&），或使用nohup：
  nohup ./bin/mywork > /var/log/mywork.log 2>&1 &

4.2 日志为空，找不到错误信息

原因：重定向未生效，或日志路径无写入权限。

解决：

• 检查日志目录权限：sudo mkdir -p /var/log/mywork && sudo chown ubuntu:ubuntu /var/log/mywork
• 改用绝对路径日志：/home/ubuntu/trx/logs/mywork.log
• 临时去掉重定向，用logger写入系统日志：logger "mywork started"

4.3 重启后进程没起来，但手动service start可以

原因：启动时机过早，依赖的服务（如数据库、网络）尚未就绪。

解决：

• 在脚本中加入简单等待：sleep 10（粗暴但有效）
• 更优解：在Required-start字段中明确声明依赖，如$network已包含，可追加$mysql（需对应服务名）

4.4 如何卸载已注册的启动项

误操作注册后想撤回？很简单：

# 移除init.d注册 sudo update-rc.d -f run.sh remove # 删除脚本文件 sudo rm /etc/init.d/run.sh # 清理日志（可选） sudo rm /var/log/mywork.log

5. 进阶建议：让启动更健壮

完成基础部署只是第一步。要让它真正成为你工作流中“隐形却可靠”的一环，还需几步加固：

5.1 添加健康检查与自动恢复

在你的主程序外，写一个简单的守护脚本，定期检查进程是否存在：

#!/bin/bash # /home/ubuntu/trx/monitor.sh if ! pgrep -f "/home/ubuntu/trx/bin/mywork" > /dev/null; then logger "mywork process died, restarting..." su -c "/home/ubuntu/trx/bin/mywork > /var/log/mywork.log 2>&1 &" -s /bin/sh ubuntu fi

然后用cron每5分钟执行一次：*/5 * * * * /home/ubuntu/trx/monitor.sh

5.2 使用systemd作为未来演进方向

虽然本文主推init.d，但长远看，systemd是Linux的未来。如果你的环境允许，可将上述脚本平滑迁移到.service文件：

# /etc/systemd/system/mywork.service [Unit] Description=My Work Service After=network.target [Service] Type=simple User=ubuntu WorkingDirectory=/home/ubuntu/trx ExecStart=/home/ubuntu/trx/bin/mywork Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

启用：sudo systemctl daemon-reload && sudo systemctl enable mywork.service

6. 总结：从手动到自动，只需六步

回顾整个过程，你真正需要做的，不过是六个清晰的动作：

1. 写一个带标准头的Shell脚本（run.sh），定义好start/stop逻辑
2. 把脚本复制到/etc/init.d/，并赋予755权限
3. 用update-rc.d注册服务，指定合理启动优先级（如96）
4. 手动测试启停，确认日志输出和进程状态
5. 重启验证，观察是否真正在无人干预下自动运行
6. 添加日志与监控，让自动化变得可观测、可维护

这并非炫技，而是把重复劳动交给机器，把宝贵注意力留给真正需要思考的问题。当你某天清晨打开电脑，发现那个曾让你每天多敲12个字符的程序，早已在后台安静运转——那一刻，你收获的不仅是效率，更是对技术掌控感的确认。

获取更多AI镜像

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