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服务
创建好服务单元文件后，需要执行以下命令来部署和管理服务：
-
重新加载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程序，可以显著提升服务的健壮性、可管理性和可靠性，使其成为生产环境中运行后台应用的首选方案。
