如何在Linux系统下配置Python程序的开机自启脚本与进程监控？-Python教程-PHP中文网

@reboot是轻量级开机自启首选方案，适合单次执行、无依赖、无需守护的脚本；需用绝对路径、显式声明环境变量（如home、path），不支持自动重启，日志需重定向排查。

如何在linux系统下配置python程序的开机自启脚本与进程监控？

现代Linux系统（Ubuntu 22.04+、CentOS 7+、Debian 10+）下，直接往 /etc/rc.local 里加 python3 /path/to/script.py & 已基本不可靠——环境变量丢失、网络未就绪、无崩溃重启、日志难查，90% 的失败都源于此。真正能落地的方案只有两个：systemd 服务（生产首选）和 crontab @reboot（轻量备选），其余方式要么过时，要么维护成本高。

systemd 服务配置：为什么必须写对 `[Unit]` 和 `[Service]`

systemd 不是“执行命令”，而是按依赖关系调度服务。写错关键字段会导致脚本启动失败或静默退出。

After=network.target 必须显式声明，否则脚本在网卡还没起来时就运行，requests 或 socket 操作全报 ConnectionRefusedError
User= 字段不能省略。用 root 运行有安全风险；用普通用户时，WorkingDirectory= 必须设为该用户有读写权限的路径，否则 open() 写日志会 PermissionDenied
Environment="PATH=..." 是 conda/virtualenv 用户的救命字段。不加这行，conda activate myenv 在 service 里根本找不到命令，ExecStart 直接报 Command not found
RestartSec=5 建议设为 5 秒以上。太快重启可能触发 systemd 的速率限制，导致服务被 start-limit-hit 锁死

示例最小可用配置（存为 /etc/systemd/system/myscript.service）：

[Unit]
Description=Data collector daemon
After=network.target

[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi/scripts
Environment="PATH=/home/pi/miniconda3/envs/collector/bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=/home/pi/miniconda3/envs/collector/bin/python /home/pi/scripts/collector.py
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

crontab @reboot：适合什么场景？怎么避免“执行了但没生效”

@reboot 本质是用户级定时任务，不依赖 systemd，适合单次启动、无依赖、无需进程守护的脚本（比如初始化配置、发一次通知、备份快照）。但它没有服务级别的生命周期管理。

Python 3.14.2

Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。

下载

绝对路径必须完整：@reboot /usr/bin/python3 /home/user/backup.py > /tmp/backup.log 2>&1 —— python3 不能只写 python，因为 cron 的 PATH 极简，which python 结果很可能不生效
环境变量默认为空。如果脚本依赖 $HOME 或自定义变量，得在 crontab 里显式导出：@reboot HOME=/home/user /usr/bin/python3 ...
它只在开机时跑一次。脚本中途崩溃不会重拉，也没 Restart= 机制。别用它跑 long-running 的 Web server 或采集 daemon
调试时用 sudo -u user bash -c 'env | grep -E "^(HOME|PATH)"' 模拟 cron 环境，比猜快得多

进程监控与日志排查：`systemctl status` 之后该看什么

systemctl status myscript 只显示最后几行状态，真正的问题往往藏在 journal 日志里。

查实时输出：journalctl -u myscript -f（-f 表示 follow，像 tail -f）
查历史全部日志：journalctl -u myscript --since "2026-07-01 10:00:00"，配合脚本里 print() 或 logging.info() 定位时间点
常见错误模式：
- Failed at step EXEC spawning → ExecStart 路径错，或 Python 解释器没权限执行
- code=exited, status=1/FAILURE → 脚本第一行就抛异常，比如 import 失败、配置文件不存在
- start-limit-hit → 10 秒内连续崩溃 5 次，systemd 主动停服。先 sudo systemctl reset-failed myscript，再查日志根因
脚本自己加日志比依赖 systemd 更可靠：logging.basicConfig(filename='/var/log/myscript.log', level=logging.INFO)，避免 journal 被轮转清空

conda 环境激活的坑：别在 `ExecStart` 里写 `source` 或 `conda activate`

systemd service 的 shell 是 /bin/sh，不支持 source，也不认识 conda activate 命令——它只在 bash 里注册了 alias/function。

正确做法：用 conda 环境里的 Python 解释器绝对路径，如 /home/user/miniconda3/envs/myenv/bin/python
或者，在 [Service] 中用 ExecStart=/bin/bash -c 'source /etc/profile.d/conda.sh && conda activate myenv && exec python /path/script.py'，但必须加 exec，否则 bash 进程会卡住，systemd 认为服务没真正启动
更稳妥的是把 conda 环境打包成可执行脚本：conda env export > environment.yml，部署时用 conda env create -f environment.yml，确保解释器路径稳定

最易被忽略的一点：systemd 默认不读取用户的 ~/.bashrc 或 /etc/environment，所有路径、变量、激活逻辑都得显式写进 service 文件里——没写，就是不存在。