☰

为什么带有workers的gunicorn作为守护进程会杀死MySQL？

tag-icon • tag-icon debian systemd mysql thread wsgi
为什么带有workers的gunicorn作为守护进程会杀死MySQL？

因此，我最近使用 Gunicorn 部署了我的第一个 Flask 应用程序。在部署过程中，我遇到了最奇特的问题。我创建了一个 systemd 单元文件（以下是工作的功能示例）:

[Unit]
Description=Gunicorn instance for newscrape
After=network.target
After=mysql.service
Requires=mysql.service

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/newscrape
Environment="PATH=/var/www/newscrape/newscrapeenv/bin"
ExecStart=/var/www/newscrape/newscrapeenv/bin/gunicorn --bind 127.0.0.1:9001 run:app

[Install]
WantedBy=multi-user.target

现在，这工作正常，但这不是我最初想要的。 我的执行启动行原文如下：ExecStart=/var/www/newscrape/newscrapeenv/bin/gunicorn --workers 4 --bind 127.0.0.1:9001 run:app

当我尝试启用并启动单元文件时，我创建的服务和 MySQL 服务都开始遇到崩溃循环。随后，两项服务可怕地在火焰中化为无休无止的华尔兹。

运行命令：ss -tln既不显示服务侦听，也不显示在任何给定时间运行的两个服务之一。

我的问题是：为什么带有worker的gunicorn会使MySQL服务器崩溃，而没有worker的gunicorn却不会？

答案1

如果文档正确http://docs.gunicorn.org/en/stable/run.html，似乎只缺少等号，例如--workers=4

相关内容