systemctl重启Gunicorn残留进程致数据库问题排查求助

可能原因 #

• Gunicorn worker进程未被彻底终止，残留进程持有失效的MySQL连接，新进程启动后引发连接池冲突或使用无效连接，触发SQLAlchemy驱动层错误。
• systemd默认的进程终止逻辑可能只杀死Gunicorn master进程，worker进程成为孤儿进程继续运行，占用数据库连接资源。

解决方案 #

1. 手动清理所有残留Gunicorn进程 #

执行命令强制终止所有Gunicorn相关进程：

sudo pkill -f gunicorn

清理完成后重新启动服务：

sudo systemctl start gunicorn

2. 强化systemd服务的进程清理逻辑 #

编辑/etc/systemd/system/gunicorn.service，在[Service]段添加以下配置：

[Service]
# 保留原有配置，新增以下内容
KillMode=process
TimeoutStopSec=15
ExecStopPost=/usr/bin/pkill -f gunicorn

添加ExecStopPost确保服务停止后自动清理所有Gunicorn进程，然后重新加载systemd配置：

sudo systemctl daemon-reload

3. 优化SQLAlchemy连接池配置 #

在Flask应用的数据库初始化代码中，添加连接有效性检查和回收机制：

from sqlalchemy import create_engine
from flask_sqlalchemy import SQLAlchemy

# 直接使用create_engine的场景
engine = create_engine(
    "mysql+pymysql://<user>:<password>@<host>/<db_name>",
    pool_pre_ping=True,  # 获取连接前自动检查有效性
    pool_recycle=3600,   # 每小时强制回收连接
    pool_timeout=10      # 连接超时时间
)

# 使用Flask-SQLAlchemy的场景
app.config["SQLALCHEMY_DATABASE_URI"] = "mysql+pymysql://<user>:<password>@<host>/<db_name>"
app.config["SQLALCHEMY_ENGINE_OPTIONS"] = {
    "pool_pre_ping": True,
    "pool_recycle": 3600,
    "pool_timeout": 10
}
db = SQLAlchemy(app)

pool_pre_ping会自动检测并丢弃失效连接，避免因残留进程的旧连接导致驱动错误。

4. 避免直接重启，分步操作并验证 #

每次代码更新后，先执行停止命令并确认进程已全部终止：

sudo systemctl stop gunicorn
# 验证进程是否清理干净
ps aux | grep gunicorn

如果仍有残留进程，手动执行pkill -f gunicorn清理，再启动服务：

sudo systemctl start gunicorn

内容的提问来源于stack exchange，提问作者Nils Deschrijver