起初:
-
uwsgi 是 binary protocol that uWSGI uses to communicate with other servers。 uWSGI 是应用服务器。
- 如果你关心子进程(worker),你应该避免(1,2)使用
-9(SIGKILL)来停止进程
根据你的信息我能说什么:
每当我使用以下命令关闭 uwsgi 时,另一个 uwsgi 工作人员
几秒钟后重生
看起来您试图杀死工作(子)进程而不是 uWSGI 应用程序服务器(主进程)。这是您的配置中的processes = 4,因此应用程序服务器(主进程)监视最少运行的工作人员(子进程)。如果其中一个退出(通过KILL 信号或源代码异常,不管)应用程序服务器启动新的第四个进程。
所以在关闭 uwsgi 进程并再次启动 uwsgi 服务器后
如果uwsgi process 是工作人员(子进程) - 请参阅上面的答案
如果uwsgi process 是应用服务器(主进程) - 这是另一个问题。您使用KILL (-9) 信号停止服务器。这不允许正确退出应用程序(请参阅at first 的第二点)。因此,当您的应用程序服务器意外终止时,它会使所有 4 个子进程在没有父(主)进程的情况下运行(向 orphaned process 打个招呼)
您应该使用SIGTERM instdead of SIGKILL。你明白die-on-term = true的意思吗?是的!这意味着please stop stack of all processes on SIGTERM。
uwsgi --stop /tmp/MyProject.pid
这个命令should stop所有进程正常。您的问题中没有任何信息可以确定可能是什么问题...
我有三个猜测:
- web应用源码问题:退出操作处理不当
-
die-on-term = true inverts the meanings of SIGTERM and SIGQUIT to uWSGI,所以在这种情况下,stop 可能像 reload 一样工作?不确定。
- 某种误解
更新一:如何动态控制子进程的数量
此外,您可以查看此helpful article 以了解如何动态扩展和扩展子进程,以便仅在需要时运行所有第 4 个进程,并在服务空闲时仅运行 1 个进程。
更新 2:检查行为是否可重现
我创建了简单的 uWSGI 应用程序来检查行为:
opt
`-- wsgi_example
|-- app.py
`-- wsgi.ini
[uwsgi]
chdir = /opt/wsgi_example
module = app
master = true
pidfile = /opt/wsgi_example/app.pid
single-interpreter = true
die-on-term = true
processes = 2
socket = /opt/wsgi_example/app.sock
chmod-socket = 666
vacuum = true
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return [b"Hello World"]
我通过wsgi wsgi.ini运行这个应用程序
我通过uwsgi --stop app.pid停止了这个应用程序
输出是
spawned uWSGI master process (pid: 15797)
spawned uWSGI worker 1 (pid: 15798, cores: 1)
spawned uWSGI worker 2 (pid: 15799, cores: 1)
SIGINT/SIGQUIT received...killing workers...
worker 1 buried after 1 seconds
worker 2 buried after 1 seconds
goodbye to uWSGI.
VACUUM: pidfile removed.
VACUUM: unix socket /opt/wsgi_example/app.sock removed.
一切正常。所有进程都已停止。
您的问题不可重现。
在应用程序代码或您的个人基础架构配置中搜索问题。
※与uWSGI 2.0.8和2.0.19.1和python 3.6.7核对