root@www:~# ps aux | grep uwsgi
root 4660 0.0 0.0 10620 892 pts/1 S+ 19:13 0:00 grep --color=auto uwsgi
root 19372 0.0 0.6 51228 6628 ? Ss 06:41 0:03 uwsgi --master --die-on-term --emperor /var/www/*/uwsgi.ini
root 19373 0.0 0.1 40420 1292 ? S 06:41 0:03 uwsgi --master --die-on-term --emperor /var/www/*/uwsgi.ini
www-data 19374 0.0 1.9 82640 20236 ? S 06:41 0:03 /usr/local/bin uwsgi --ini /var/www/app2/uwsgi.ini
www-data 19375 0.0 2.4 95676 25324 ? S 06:41 0:03 /usr/local/bin uwsgi --ini /var/www/app3/uwsgi.ini
www-data 19385 0.0 2.1 90772 22248 ? S 06:41 0:03 /usr/local/bin uwsgi --ini /var/www/app2/uwsgi.ini
www-data 19389 0.0 2.0 95676 21244 ? S 06:41 0:00 /usr/local/bin uwsgi --ini /var/www/app3/uwsgi.ini
以上是uwsgi进程的ps
输出。奇怪的是,对于每个ini文件都有两个实例被加载-即使我有两个uwsgi主机。这正常吗?在
uwsgi的部署策略是
uwsgi.ini
uwsgi.conf公司对于新贵:
^{pr2}$uwsgi.ini文件(我有两个应用程序,除应用程序编号外,两个应用程序的ini相同):
[uwsgi]
# variables
uid = www-data
gid = www-data
projectname = myproject
projectdomain = www.myproject.com
base = /var/www/app2
# config
enable-threads
protocol = uwsgi
venv = %(base)/
pythonpath = %(base)/
wsgi-file = %(base)/app.wsgi
socket = /tmp/%(projectdomain).sock
logto = %(base)/logs/uwsgi.log
我对这个问题的有见地的猜测是,它确实应该转移到服务器故障上。 但答案是:
您应该启动upstart脚本两次;-)
只需尝试用SIGTERM终止主根进程,看看childs进程是否死了。 如果您已经运行了两次upstart脚本,那么剩下一个ROOT和两个child。在
您使用master选项启动它,该选项生成一个主进程来控制工作进程。在
从官方文件https://uwsgi-docs.readthedocs.org/en/latest/Glossary.html?highlight=master
你应该读http://uwsgi-docs.readthedocs.org/en/latest/Options.html#master 而且这个帖子可能会给你一些信息。uWSGI: master with emperor spawns two emperors
一般不建议把师父和皇帝一起使用。在
相关问题 更多 >
编程相关推荐