本文探讨了如何通过Bash脚本结合pgrep和tmux来守护Python程序可能遇到的问题，并详细介绍了使用systemd作为更健壮、更专业的解决方案。文章将指导读者创建systemd服务单元文件，配置自动重启策略，确保Python应用在系统启动时自动运行，并在意外终止后自动恢复，从而实现高效稳定的后台服务管理。
1. Bash脚本守护的局限性
许多初学者在尝试守护后台python程序时，倾向于使用bash脚本配合pgrep和tmux。这种方法看似简单，但在实际应用中常常暴露出其局限性。最初的尝试可能如下所示：
PATH=/opt/conda/bin:/opt/conda/condabin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/gameswhile true; do if /bin/pgrep -f "miner_nbeats.py" | grep -v $$ >/dev/null; then echo "script running" else echo "script not running" tmux new-session -d -s my_python_script ; send-keys "source activate python310 && cd /home/putsncalls23/directory && python miner_nbeats.py" Enter fi sleep 300done
上述脚本旨在检测miner_nbeats.py是否正在运行，如果未运行，则通过tmux在一个新的会话中启动它。然而，这种方法存在以下几个主要问题：
pgrep的误判： pgrep -f “miner_nbeats.py”命令可能会误判。当Python脚本在tmux会话中运行时，pgrep有时会匹配到tmux进程本身，或者是包含miner_nbeats.py字符串的Bash脚本（如果Bash脚本自身被检测到）。这意味着即使Python脚本已经崩溃，pgrep可能仍然报告它在运行，导致守护脚本无法触发重启。tmux管理的复杂性： 在Bash脚本中程序化地管理tmux会话（创建、连接、发送命令、检测其内部进程状态）会增加脚本的复杂性，并且容易出错。环境激活问题： 在tmux会话中执行source activate python310需要一个交互式shell环境，这在非交互式脚本中可能不够稳定或预期。缺乏系统级集成： 这种Bash脚本是用户级的，无法在系统启动时自动运行，也无法与系统日志、依赖管理等功能集成。
当Python脚本因内存不足（OOM）或其他错误终止时，上述Bash脚本由于pgrep的误判，将无法有效地重新启动程序。
2. systemd：专业的服务管理方案
对于需要在Linux服务器上可靠运行的后台服务，systemd是现代Linux发行版中推荐的解决方案。systemd是一个系统和服务管理器，它提供了强大的进程守护、自动重启、依赖管理、日志集成和资源控制等功能。
使用systemd来守护Python程序，可以避免Bash脚本的诸多问题，实现更稳定、更专业的服务管理。
立即学习“Python免费学习笔记（深入）”；
3. 创建systemd服务单元文件
要使用systemd守护Python程序，需要创建一个服务单元（Service Unit）文件。这个文件通常存放在/etc/systemd/system/目录下，并以.service为后缀。
假设我们要守护的Python脚本是miner_nbeats.py，位于/home/putsncalls23/directory，并且使用名为python310的conda环境。我们可以创建一个名为miner_nbeats.service的文件，内容如下：
# /etc/systemd/system/miner_nbeats.service[Unit]Description=Mining service for nbeatsAfter=network.target[Service]Type=simpleUser=putsncalls23WorkingDirectory=/home/putsncalls23/directoryExecStart=/opt/conda/envs/python310/bin/python miner_nbeats.pyRestart=alwaysRestartSec=300[Install]WantedBy=multi-user.target
服务单元文件解析：
[Unit] 部分：Description: 对服务的简短描述，方便识别。After=network.target: 定义了服务启动的顺序。network.target表示在网络服务可用后才启动此服务。[Service] 部分：Type=simple: 指定服务类型。simple表示ExecStart中定义的命令是主进程。User=putsncalls23: 指定运行此服务的用户。强烈建议使用非root用户运行服务，以提高安全性。WorkingDirectory=/home/putsncalls23/directory: 指定服务的工作目录。ExecStart中的相对路径将以此目录为基准。ExecStart=/opt/conda/envs/python310/bin/python miner_nbeats.py: 定义启动服务的命令。这里直接指定了conda环境中Python解释器的绝对路径，确保了环境的正确激活，避免了source activate的复杂性。Restart=always: 这是实现自动重启的关键指令。它告诉systemd，无论服务以何种方式退出（正常退出、错误退出、被信号终止），都应尝试重启它。RestartSec=300: 指定在尝试重启服务前等待的秒数（这里是300秒，即5分钟）。这可以防止服务在快速崩溃-重启循环中消耗过多系统资源。[Install] 部分：WantedBy=multi-user.target: 定义了服务在哪个target下被启用。multi-user.target表示在多用户命令行模式下（即系统正常启动后）启用此服务。
4. 部署与管理systemd服务
创建好服务单元文件后，需要执行以下命令来部署和管理服务：
重新加载systemd配置：
sudo systemctl daemon-reload
此命令通知systemd重新扫描服务单元文件，使其识别新创建的服务。
启用服务（开机自启动）：
sudo systemctl enable miner_nbeats.service
此命令会在系统启动时创建必要的符号链接，确保miner_nbeats.service在系统启动时自动运行。
立即启动服务：
sudo systemctl start miner_nbeats.service
此命令会立即启动miner_nbeats服务。
常用管理命令：
查看服务状态：
systemctl status miner_nbeats.service
这将显示服务的当前状态、PID、内存使用、最近的日志输出等信息。
停止服务：
sudo systemctl stop miner_nbeats.service
禁用服务（取消开机自启动）：
sudo systemctl disable miner_nbeats.service
查看服务日志：
journalctl -u miner_nbeats.service -f
-f选项可以实时跟踪日志输出。
5. 注意事项与最佳实践
绝对路径： 在ExecStart中，务必使用Python解释器和脚本的绝对路径，以确保在任何环境下都能正确执行。用户权限： 始终使用User=指令以非root用户运行服务，遵循最小权限原则。错误处理与日志： systemd会自动捕获服务的标准输出和标准错误，并将其转发到journalctl。这对于调试服务至关重要。确保Python脚本内部有适当的日志记录机制，以便通过journalctl进行分析。资源限制： systemd允许在服务单元文件中设置内存、CPU、文件描述符等资源限制，例如MemoryLimit=500M。这对于防止服务耗尽系统资源非常有用，尤其是在处理OOM问题时。依赖管理： After=和Requires=等指令可以精确控制服务的启动顺序和依赖关系，确保在所有必要条件满足后才启动服务。
通过采用systemd来守护Python程序，可以显著提升服务的健壮性、可管理性和可靠性，使其成为生产环境中运行后台应用的首选方案。
以上就是使用systemd守护Python程序：告别Bash脚本的局限性的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1372290.html
微信扫一扫 
支付宝扫一扫 
