使用systemd守护Python程序：告别Bash脚本的局限性

本文探讨了如何通过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/games while 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 300 done

上述脚本旨在检测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 nbeats After=network.target  [Service] Type=simple User=putsncalls23 WorkingDirectory=/home/putsncalls23/directory ExecStart=/opt/conda/envs/python310/bin/python miner_nbeats.py Restart=always RestartSec=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服务

创建好服务单元文件后，需要执行以下命令来部署和管理服务：

1. 重新加载systemd配置：

   sudo systemctl daemon-reload

   此命令通知systemd重新扫描服务单元文件，使其识别新创建的服务。

2. 启用服务（开机自启动）：

   sudo systemctl enable miner_nbeats.service

   此命令会在系统启动时创建必要的符号链接，确保miner_nbeats.service在系统启动时自动运行。

   

   AirOps

   AirOps帮助业务团队使用正确的数据创建表、文档和工具

   20

   查看详情

3. 立即启动服务：

   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程序，可以显著提升服务的健壮性、可管理性和可靠性，使其成为生产环境中运行后台应用的首选方案。