核心内容摘要
【Linux】screen 命令创建会话 保持后台运行
亲自动手搭建从创建到启用全程实录演示你是否遇到过这样的问题写好了一个Python脚本希望它在系统启动时自动运行但每次重启后都得手动执行或者试了几次rc.local却始终没看到预期效果日志里空空如也服务状态显示“inactive”别急——这不是你的操作错了而是Ubuntu
1
04及后续版本对开机自启机制做了根本性调整。
老办法失效了但新方法其实更可靠、更清晰只是少有人把每一步的真实反馈和常见卡点讲透。
本文不讲抽象原理不堆术语只带你亲手走完从零创建到验证生效的完整闭环。
每一步都基于真实终端操作截图逻辑还原所有命令可直接复制粘贴所有报错都有对应解法。
你会看到为什么/etc/rc.local默认不工作怎样让systemd真正“认出”这个传统脚本入口如何安全地把业务逻辑比如Python程序嵌入启动流程出现失败时第一眼该看哪条日志、查哪个状态、改哪行代码。
准备好了吗我们这就开始——不是模拟是实录。
理解变化为什么老方法在Ubuntu
1
04上失效了在Ubuntu
1
04时代编辑/etc/rc.local几乎是开机自启的“万能钥匙”。
但到了
1
04系统全面转向systemd管理服务而rc.local本身只是一个遗留兼容接口——它不再被默认启用也不再由init自动加载。
简单说文件还在但没人读它。
这带来两个关键事实即使你把命令写进/etc/rc.local只要没有配套的systemd服务单元.service文件它就永远不会被执行rc.local的执行权限、退出码、路径环境全部受systemd服务定义约束不再是过去那种“扔进去就跑”的宽松模式。
所以真正的起点不是写脚本而是先让systemd认识并信任rc.local这个入口。
下面这一步决定了整条链路能否打通。
创建rc-local.service给rc.local装上systemd“驱动”这一步是整个方案的基石。
我们需要告诉systemd“请把/etc/rc.local当作一个合法服务来管理并在多用户模式下启动它。
”
1 创建服务定义文件打开终端执行sudo vim /etc/systemd/system/rc-local.service将以下内容完整粘贴进去注意不要漏掉任何一行尤其是空行和缩进[Unit] Description/etc/rc.local Compatibility ConditionPathExists/etc/rc.local [Service] Typeforking ExecStart/etc/rc.local start TimeoutSec0 StandardOutputtty RemainAfterExityes SysVStartPriority99 [Install] WantedBymulti-user.target关键点说明ConditionPathExists/etc/rc.local确保只有当/etc/rc.local文件存在时该服务才被允许启用。
这是防止配置错误导致系统异常的保险机制Typeforking因为rc.local传统上会派生子进程必须声明为forking类型否则systemd会误判服务已退出RemainAfterExityes告诉systemd“即使rc.local脚本执行完了也请继续保持服务为‘激活’状态”这样才能让后续依赖它的服务正常启动WantedBymulti-user.target明确指定该服务应在标准多用户运行级别即图形界面或纯命令行登录环境下启动。
保存并退出vim:wq。
2 验证服务文件语法在启用前先检查语法是否正确避免因格式错误导致服务无法加载sudo systemctl daemon-reload sudo systemctl cat rc-local.service如果输出显示完整的service内容说明文件已成功注册若提示“No such file or directory”请返回上一步检查路径和文件名是否完全一致注意大小写和后缀。
编写rc.local不只是占位而是可靠启动索引rc.local现在不是终点而是起点——它应该是一个轻量、稳定、职责单一的“启动索引”负责调用你真正的业务脚本。
这样既保持传统习惯又便于后期维护。
1 创建并编辑rc.local文件sudo vim /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 rc.local 已触发当前时间$(date) /usr/local/rc-local-triggered.log # 此处添加你的实际启动命令例如 # /home/lbw/test.sh exit 0为什么这样写#!/bin/sh -e强制使用POSIX shell并在任意命令失败时立即退出避免静默错误echo行提供最直接的执行证据——只要/usr/local/rc-local-triggered.log生成且有时间戳就证明rc.local已被systemd成功调用exit 0必须显式返回0否则systemd会认为脚本执行失败进而标记服务为failed。
2 设置执行权限sudo chmod x /etc/rc.local这步不可省略。
systemd要求rc.local必须有可执行权限否则拒绝启动。
启用并启动服务让systemd真正接管现在rc-local.service定义好了rc.local也准备就绪。
接下来让systemd把它纳入管理。
1 启用服务开机自启sudo systemctl enable rc-local.service执行后你会看到类似输出Created symlink /etc/systemd/system/multi-user.target.wants/rc-local.service → /etc/systemd/system/rc-local.service.这表示systemd已在启动目标中建立了软链接下次开机时会自动加载此服务。
2 立即启动服务无需重启sudo systemctl start rc-local.service
3 检查服务状态关键验证步骤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 ...; X seconds ago Docs: man:systemd-rc-local-generator(
重点关注两点Loaded行中的enabled确认已设置为开机启动Active行中的active (exited)表明服务已成功执行完毕注意不是running因为rc.local是短时任务。
如果看到failed或inactive立即执行sudo journalctl -u rc-local.service -n 20 --no-pager查看最近20行日志。
90%的问题都能在这里定位——比如路径不存在、权限不足、脚本语法错误等。
4 验证rc.local是否真被调用检查我们之前写的日志文件cat /usr/local/rc-local-triggered.log你应该看到类似rc.local 已触发当前时间Wed 12 Jun 2024 10:23:45 CST这证明systemd已成功驱动rc.local执行整个基础链路已通。
部署你的业务脚本以Python为例的安全集成现在rc.local已可靠运行。
下一步把你的实际任务比如一个Python程序接入进来。
这里以test.sh调用ce.py为例重点解决三个实战痛点路径问题、环境变量、中文编码。
1 创建业务脚本test.shsudo vim /home/lbw/test.sh内容如下注意路径、用户、解释器需按你实际情况修改#!/bin/bash # 切换到脚本所在目录避免相对路径错误 cd /home/lbw || exit 1 # 显式指定Python解释器路径推荐用绝对路径避免PATH差异 /usr/bin/python3 ce.py # 记录执行结果便于排查 echo test.sh 执行完成时间$(date) /usr/local/test-sh-ran.log exit 0为什么强调/usr/bin/python3在systemd服务环境下PATH环境变量与用户终端不同默认可能不包含/usr/local/bin或你的conda环境。
硬编码绝对路径是最稳妥的做法。
2 创建Python程序ce.pysudo vim /home/lbw/ce.py内容简洁版无中文字符#!/usr/bin/env python3 import os # 确保写入路径存在且可写 log_path /usr/local/sb.txt try: with open(log_path, w) as f: f.write(SB from ce.py at os.popen(date).read().strip()) print(f成功写入 {log_path}) except Exception as e: print(f写入失败{e})关键防护措施使用#!/usr/bin/env python3声明解释器同时在脚本内用/usr/bin/python3调用双重保障添加try/except捕获IO异常并打印具体错误避免静默失败os.popen(date)替代datetime.now()减少模块依赖提升兼容性。
3 赋予执行权限并更新rc.localsudo chmod x /home/lbw/test.sh然后编辑/etc/rc.local取消注释并修改调用行sudo vim /etc/rc.local将其中的# /home/lbw/test.sh改为/home/lbw/test.sh保存退出。
4 重新加载并测试sudo systemctl daemon-reload sudo systemctl restart rc-local.service sudo systemctl status rc-local.service再次检查日志cat /usr/local/sb.txt cat /usr/local/test-sh-ran.log如果看到SB from ce.py at ...和test.sh 执行完成恭喜你的业务逻辑已成功融入开机流程。
6.
常见问题与排障清单比文档更实用的实战经验即使严格按步骤操作仍可能遇到意外。
以下是根据真实部署反馈整理的高频问题及速查方案
1 服务状态显示“failed”journalctl日志为空原因rc.local文件权限不对或exit语句缺失/错误。
检查命令ls -l /etc/rc.local # 应显示 -rwxr-xr-x即包含x执行权限 head -n 5 /etc/rc.local | grep exit # 确保最后一行是 exit
0
2 test.sh能手动运行但开机时不执行原因test.sh中调用的Python脚本含中文字符或未指定-u参数导致缓冲区阻塞。
解决方案将Python脚本中的中文字符串替换为英文或在shebang后加-u#!/usr/bin/env python3 -u在test.sh中添加环境变量export PYTHONIOENCODINGutf-8。
3 写入文件失败提示“Permission denied”原因/usr/local/目录默认仅root可写而test.sh以root身份运行但Python脚本内open()可能因umask限制失败。
安全写法with open(/usr/local/sb.txt, w, encodingutf-
as f: f.write(...)并确保/usr/local/目录权限为drwxr-xr-x755。
4 修改rc.local后服务不生效必须执行的三步sudo chmod x /etc/rc.local重设权限sudo systemctl daemon-reload重载服务定义sudo systemctl restart rc-local.service重启服务缺一不可。
7.
总结一条可复用、可验证、可扩展的启动链路回看整个过程我们构建的不是一个临时补丁而是一条清晰、可控、易维护的启动链路底层驱动rc-local.service—— systemd原生服务稳定可靠统一入口/etc/rc.local—— 职责单一只做调度不掺杂业务逻辑业务载体/home/lbw/test.sh—— 可独立测试、版本管理、权限隔离最终执行ce.py—— 专注核心功能错误处理完备。
这条链路的价值在于可验证每个环节都有明确输出日志文件、服务状态、终端反馈可复用只需替换test.sh内容即可适配Shell、Python、Node.js等任意语言脚本可扩展未来可轻松增加多个.sh脚本通过rc.local顺序调用形成启动任务队列。
现在你可以放心重启系统sudo reboot等待登录后第一时间检查cat /usr/local/sb.txt sudo systemctl status rc-local.service如果一切如常那么恭喜你——不仅完成了开机自启的配置更掌握了一套在现代Linux系统中安全、可靠、可追溯的自动化部署方法论。