手把手教你设置Linux开机自动运行Python脚本
你是不是也遇到过这样的问题：写好了一个监控程序、数据采集脚本，或者一个后台服务，每次重启服务器后都要手动运行一次？既麻烦又容易忘记，关键时候还可能掉链子。其实，Linux系统早就为我们准备好了几种稳定可靠的方案，让Python脚本在开机时自动启动——而且完全不用你守在终端前。
这篇文章不讲抽象概念，不堆砌术语，只聚焦一件事：让你的Python脚本真正在开机后稳稳跑起来。我们会用最贴近实际工作的方式，带你一步步完成配置，覆盖常见坑点，比如环境变量失效、conda环境没激活、权限不足、路径错误等。无论你是刚接触Linux的新手，还是想确认最佳实践的开发者，都能照着操作直接落地。
全文基于真实测试环境（Ubuntu 22.04 + Python 3.9 + conda环境），所有命令和配置都经过验证。我们不推荐“能跑就行”的临时方案，而是提供两种主流、健壮、可维护的方法：Systemd服务方式（推荐）和Crontab @reboot方式（轻量备选）。你会清楚知道每种方法适合什么场景，以及为什么这样写。
1. 为什么不能直接把Python命令丢进/etc/rc.local？
在开始正题前，先说一个常见误区：很多人第一反应是修改/etc/rc.local，在里面加一行python3 /path/to/script.py &。这确实能在老版本系统中“凑合用”，但在现代Linux发行版（尤其是使用systemd的Ubuntu、CentOS 7+、Debian 10+）中，/etc/rc.local 默认已禁用，且即使启用也存在严重隐患：
- 环境变量缺失：
rc.local运行在极简shell环境中，PATH、HOME、CONDA_DEFAULT_ENV等全都不生效，你的conda环境根本找不到； - 启动时机不可控：它在所有服务之前执行，网络、磁盘挂载可能还没就绪，脚本一启动就报错；
- 没有进程管理：脚本崩溃后不会自动重启，也没有日志记录，出问题只能靠猜；
- 安全策略限制：许多发行版默认禁用rc.local，需额外启用，违背最小权限原则。
所以，我们跳过这个“历史遗留方案”，直接上现代、标准、可控的两种方法。
2. 方法一：用Systemd服务（强烈推荐）
Systemd 是当前Linux主流的初始化系统和服务管理器。把它用作Python脚本的守护进程，就像给脚本配了个专业管家：自动拉起、崩溃自愈、日志归档、依赖控制、权限隔离，样样齐全。这是生产环境的首选方案。
2.1 创建服务文件
首先，我们需要为你的Python脚本创建一个专属的systemd服务定义文件。这个文件告诉systemd：“当系统启动到多用户模式时，请帮我运行这个脚本，并按以下规则管理它。”
打开终端，用root权限创建服务文件（注意路径必须是/etc/systemd/system/）：
sudo nano /etc/systemd/system/my_python_script.service小提示：文件名建议用小写字母、下划线和
.service后缀，避免空格和特殊字符。my_python_script可以替换成你自己的有意义名称，比如data_collector.service或camera_monitor.service。
2.2 编写服务配置（关键！逐行解析）
将以下内容完整复制进编辑器，然后根据你的实际情况修改括号中的部分：
[Unit] Description=我的Python数据采集脚本 After=network.target multi-user.target StartLimitIntervalSec=0 [Service] Type=simple User=test WorkingDirectory=/home/test/stu_zx/2/ultralytics-main ExecStart=/home/test/anaconda3/envs/pytorch_env/bin/python /home/test/stu_zx/2/ultralytics-main/1.py Restart=always RestartSec=10 StandardOutput=journal StandardError=journal SyslogIdentifier=my-python-script [Install] WantedBy=multi-user.target现在，我们逐段解释每一行的作用，帮你真正理解而不仅是复制：
Description=：服务的描述，纯文本，方便你日后用systemctl status查看时一眼认出；After=：指定该服务应在哪些目标（target）之后启动。network.target确保网络已就绪；multi-user.target是标准的多用户运行级别（即你登录Shell的状态）；StartLimitIntervalSec=0：取消启动失败次数限制（默认10秒内失败5次就停用），避免调试期被锁死；Type=simple：表示服务主进程就是ExecStart启动的那个进程（最常用）；User=：必须指定运行用户！不要用root，用你日常登录的普通用户（如test）。这保证了环境变量、家目录、conda路径全部正确；WorkingDirectory=：设置脚本的工作目录。很多Python脚本会用相对路径读取配置或保存日志，这里必须设对；ExecStart=：核心命令。这里我们不调用source activate，而是直接使用conda环境里Python解释器的绝对路径。这是最可靠、最干净的方式。路径格式为：/your/conda/path/envs/your_env_name/bin/python。你可以通过在终端运行which python（先激活环境）来确认；Restart=always：脚本退出（无论成功或失败）后，systemd都会自动重启它；RestartSec=10：重启前等待10秒，避免高频崩溃打满日志；StandardOutput/StandardError=journal：将脚本的标准输出和错误输出重定向到systemd日志系统（journald），方便统一查看；SyslogIdentifier=：为日志打上自定义标签，后续查日志时过滤更精准；WantedBy=multi-user.target：表示把这个服务“启用”（enable）时，它会链接到multi-user.target，也就是开机自启。
修改完成后，按Ctrl+O保存，Ctrl+X退出nano编辑器。
2.3 启用并启动服务
配置写完只是第一步，还需要通知systemd加载新服务，并设置开机自启：
# 重新加载所有service文件，让systemd“看到”新服务 sudo systemctl daemon-reload # 启用服务：设置为开机自动启动 sudo systemctl enable my_python_script.service # 立即启动服务（无需重启） sudo systemctl start my_python_script.service2.4 验证与排错（三步法）
服务是否真的跑起来了？别猜，用systemd自带的工具验证：
检查服务状态：
sudo systemctl status my_python_script.service正常输出中应包含
active (running)和最近几行日志。如果显示failed或inactive，重点看Main PID和Status:后面的错误信息。实时查看日志（最有效！）：
# 查看全部日志（从最早开始） sudo journalctl -u my_python_script.service # 实时跟踪最新日志（像tail -f一样） sudo journalctl -u my_python_script.service -f日志里会清晰显示Python脚本的print输出、报错堆栈、甚至conda环境路径是否正确。这是你排错的第一手资料。
模拟重启测试：
# 重启系统（谨慎操作，确保有远程连接或备份） sudo reboot重启后，再次运行
systemctl status和journalctl确认服务已自动运行。
常见报错及解决：
Permission denied：检查User=是否为你有权限的用户，WorkingDirectory路径是否存在且有读写权限；No module named xxx：说明Python解释器路径不对，确认ExecStart=中的python路径是否指向你conda环境里的那个；Failed to start ...: Unit not found：检查服务文件名是否为.service结尾，路径是否在/etc/systemd/system/下，daemon-reload是否执行。
3. 方法二：用Crontab @reboot（轻量级备选）
如果你的脚本非常简单（比如只做一次初始化，不需要持续守护），或者你暂时不想深入systemd，crontab @reboot是一个快速、低侵入的替代方案。它的原理是：cron守护进程在系统启动时，会扫描用户的crontab，执行标记为@reboot的任务。
3.1 创建可执行启动脚本
因为cron环境极其精简，我们不能直接在crontab里写source activate && python script.py，而要先封装成一个独立的、带完整环境的shell脚本。
# 创建脚本文件（注意：用你的用户名替换 test） nano /home/test/start_my_script.sh写入以下内容（务必替换所有占位符）：
#!/bin/bash # 设置语言环境（避免locale警告） export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8 # 切换到脚本所在目录（重要！） cd /home/test/stu_zx/2/ultralytics-main # 激活conda环境（使用绝对路径） source /home/test/anaconda3/bin/activate pytorch_env # 运行Python脚本 python 1.py # 退出conda环境（可选，但推荐） conda deactivate保存退出后，必须赋予执行权限，否则cron无法运行：
chmod +x /home/test/start_my_script.sh3.2 添加到用户Crontab
切换到你的目标用户（比如test），编辑其crontab：
# 切换用户（如果当前不是test） su - test # 编辑自己的crontab crontab -e在打开的编辑器末尾，添加这一行：
@reboot /home/test/start_my_script.sh >> /home/test/cron_log.txt 2>&1解释：
@reboot：关键词，表示系统启动时执行；/home/test/start_my_script.sh：你刚创建的脚本的绝对路径；>> /home/test/cron_log.txt 2>&1：将脚本的所有输出（stdout和stderr）追加写入cron_log.txt文件，方便后续排查。这个日志文件会生成在test用户家目录下。
保存退出。此时，cron已监听该任务。
3.3 测试与验证
立即测试：不用重启，直接运行脚本看是否成功：
/home/test/start_my_script.sh检查
cron_log.txt是否有输出。重启验证：
sudo reboot，重启后检查cron_log.txt是否有新的启动日志。
优点：配置简单，适合一次性任务或快速验证。
❌ 缺点：无进程守护（脚本退出即结束）、无自动重启、日志分散、环境变量管理不如systemd严谨。
4. 两种方法怎么选？一张表说清
| 对比维度 | Systemd服务（推荐） | Crontab @reboot（备选） |
|---|---|---|
| 适用场景 | 长期运行的守护进程（如Web服务、监控、API） | 一次性启动任务（如初始化数据库、发送通知） |
| 崩溃恢复 | 自动重启，可配置重启策略 | ❌ 退出即停止，不重启 |
| 日志管理 | 统一集成journald，journalctl一键查询 | 需手动重定向，日志分散 |
| 环境变量 | User=自动继承用户环境，WorkingDirectory明确 | 需在脚本中手动source和export |
| 依赖控制 | 可精确指定After=、Wants=等依赖关系 | ❌ 无依赖概念，启动时机不可控 |
| 学习成本 | 略高，但掌握后受益终身 | 极低，几分钟上手 |
| 生产环境推荐度 | ★★★★★ | ★★☆☆☆ |
结论：除非你100%确定脚本只需运行一次且永不中断，否则请无脑选择Systemd。它不是“更高级”，而是“更正确”。
5. 实用技巧与避坑指南
最后，分享几个在真实项目中反复验证过的经验，帮你绕开90%的坑：
5.1 如何找到你conda环境里Python的绝对路径？
别再猜~/anaconda3/envs/xxx/bin/python。最稳妥的方法是：
- 先手动激活你的环境：
conda activate pytorch_env - 然后运行：
which python - 复制输出的完整路径，粘贴到
ExecStart=中。
5.2 脚本里如何优雅处理相对路径？
在Python脚本开头，加上这几行，让它无论在哪启动，都能准确定位自身目录：
import os # 获取当前脚本所在目录（绝对路径） script_dir = os.path.dirname(os.path.abspath(__file__)) # 切换工作目录（可选，但推荐） os.chdir(script_dir) # 现在 './config.json' 就一定在脚本同目录下5.3 如何让脚本安静地在后台运行，不弹窗不占终端？
- Systemd：默认就是后台守护，无需额外操作。
- Crontab：脚本中最后一行加
&并重定向输出，例如python 1.py > /dev/null 2>&1 &，但更推荐用上面的>> log.txt 2>&1方式，保留日志更安全。
5.4 忘记密码或服务卡死怎么办？
- 临时禁用服务（不删除文件）：
sudo systemctl disable my_python_script.service sudo systemctl stop my_python_script.service - 彻底删除服务：
sudo systemctl stop my_python_script.service sudo systemctl disable my_python_script.service sudo rm /etc/systemd/system/my_python_script.service sudo systemctl daemon-reload
6. 总结：你已经掌握了Linux开机自启的核心能力
回顾一下，你刚刚完成了：
- 理解了为什么
/etc/rc.local不再是首选； - 学会了用Systemd创建一个健壮、可监控、可重启的Python服务；
- 掌握了用Crontab实现轻量级开机启动的完整流程；
- 获得了真实可用的排错方法（
systemctl status+journalctl）； - 收获了一套经过实战检验的避坑清单。
现在，你的Python脚本不再是需要你每天手动唤醒的“宠物”，而是一个能自主呼吸、自我修复的“数字员工”。无论是部署在树莓派上的家庭自动化，还是云服务器上的AI推理服务，这套方法都经得起时间考验。
下一步，你可以尝试：
- 给服务添加健康检查（比如定期ping一个URL）；
- 将日志接入ELK或Grafana进行可视化；
- 用
systemctl set-property限制脚本的内存/CPU使用率。
技术的价值，永远在于它能否让生活更简单一点。希望这篇手把手教程，真的帮你省下了下一个凌晨三点的手动重启。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
