uwsgi过程不呼吸

Question

目前使用django + uwsgi + nginx安装程序将web - app服务器服务器化。如果呼吸过程由于django中糟糕的python代码而死亡，我目前遇到了困难。

因为我是个很差的程序员，这种情况经常发生。我以为uwsgi只会重生一个死掉的过程。

我的配置文件如下:对于我的UWSGI文件：

[uwsgi]
# variables
projectname = testapp
base = /home/ubuntu/testapp
# config
protocol = uwsgi
pythonpath = %(base)/src/%(projectname)
module = %(projectname).wsgi
socket = /tmp/%(projectname).sock
logto = %(base)/logs/uwsgi.log 

chmod-socket = 777
processes = 2
master = 1
harakiri-verbose = true

还有我的nginx档案：

server {
  listen 80;
  server_name mytestserver;
  location / {
    include uwsgi_params;
    uwsgi_read_timeout 300;
    uwsgi_pass unix:///tmp/testapp.sock;  

  }
  access_log /home/ubuntu/testapp/logs/access.log;
  error_log /home/ubuntu/testapp/logs/error.log;
}

我为nginx和uwsgi创建了init.d文件。我用皇帝的方式管理我的巫术。将它指向我保存uwsgi.ini文件的文件夹(它的符号链接到/etc/uwsgi/vassals)

我的UWSGI日志如下所示:请注意PID数字:我从12363和12365开始，进程，转到我在django代码Why die here now中所做的打印消息，然后只剩下进程12363，然后它就死了。我的网络应用程序拒绝加载任何东西(这部分是有道理的)

[pid: 12365|app: 0|req: 85/174] 123.123.123.123 () {32 vars in 414 bytes} [Thu Oct 10 02:31:58 2013] POST /test1=> generated 9 bytes in 4 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0)

[pid: 12365|app: 0|req: 86/175] 123.123.123.123 () {32 vars in 414 bytes} [Thu Oct 10 02:31:58 2013] POST /test1 => generated 9 bytes in 3 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0)

[pid: 12363|app: 0|req: 87/176] 123.123.123.123 () {32 vars in 414 bytes} [Thu Oct 10 02:31:59 2013] POST /test1 => generated 9 bytes in 4 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0)
why break here now?

[pid: 12363|app: 0|req: 88/177] 123.123.123.123 () {32 vars in 414 bytes} [Thu Oct 10 02:32:02 2013] POST /test1 => generated 9 bytes in 5 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0)

[pid: 12363|app: 0|req: 89/178] 123.123.123.123 () {32 vars in 414 bytes} [Thu Oct 10 02:32:02 2013] POST /test1 => generated 9 bytes in 7 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0)

我以为皇帝会重生附庸，但附庸没有死？我可以重新启动所有东西，如果bit...then死掉了，一切正常。

Answer 1

如果进程死亡，您应该在日志中看到有关其死亡的消息。您确定您的流程不是简单地被卡住了吗？您已经启用了harakiri详细，但没有原基里，因此将不会监视卡住的请求。