在Debian上服務器崩潰后，uWSGI突然不會再次啟動

Question

服務器崩潰后，我無法再次啟動uWSGI，並且繼續在unlink()和bind()上出現以下錯誤。

我以root用戶身份啟動服務，因此使它變得更加奇怪。

Sun Nov 16 15:25:24 2014 - *** Starting uWSGI 1.2.3-debian (64bit) on [Sun Nov 16 15:25:24 2014] ***
Sun Nov 16 15:25:24 2014 - compiled with version: 4.7.2 on 06 July 2013 12:20:09
Sun Nov 16 15:25:24 2014 - detected number of CPU cores: 1
Sun Nov 16 15:25:24 2014 - current working directory: /
Sun Nov 16 15:25:24 2014 - writing pidfile to /run/uwsgi/app/myserver_dev/pid
Sun Nov 16 15:25:24 2014 - detected binary path: /usr/bin/uwsgi-core
Sun Nov 16 15:25:24 2014 - setgid() to 33
Sun Nov 16 15:25:24 2014 - setuid() to 33
Sun Nov 16 15:25:24 2014 - writing pidfile to /var/www/servers/myserver/development/logs/myserver.pid
Sun Nov 16 15:25:24 2014 - your memory page size is 4096 bytes
Sun Nov 16 15:25:24 2014 - detected max file descriptor number: 1024
Sun Nov 16 15:25:24 2014 - lock engine: pthread robust mutexes
Sun Nov 16 15:25:24 2014 - uwsgi socket 0 bound to UNIX address /run/uwsgi/app/myserver_dev/socket fd 3
Sun Nov 16 15:25:24 2014 - unlink(): Permission denied [socket.c line 75]
Sun Nov 16 15:25:24 2014 - bind(): Address already in use [socket.c line 107]

Nginx服務器：

server {
    access_log      /var/www/servers/example/development/logs/nginx_access.log;
    error_log       /var/www/servers/example/development/logs/nginx_error.log;
    listen          8181;
    server_name     example.com;
    charset         utf-8;
}

server {
    listen  80;
    server_name *.example.com;
    return 301 http://example.com$request_uri;
}

server {
    access_log      /var/www/servers/example/production/logs/nginx_access.log;
    error_log       /var/www/servers/example/production/logs/nginx_error.log;
    listen          80;
    server_name     example.com;
    charset         utf-8;    
}

server {
    listen          7777;
    server_name     example.com;
    charset         utf-8;
    root            /var/www/servers/phpmyadmin;
    index           index.php   index.html  index.htm;

    if (!-e $request_filename) {
        rewrite ^/(.+)$ /index.php?url=$1 last;
        break;
    }

    location ~ .php$ {
        allow       2.110.234.34;
        deny        all;
        try_files $uri =404;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include /etc/nginx/fastcgi_params;
    }
}

uWSGI配置開發：

[uwsgi]
master = true
workers = 2
socket = /var/www/servers/example/development/sockets/example.sock
chmod-socket = 666
log-date = true
uid = www-data
gid = www-data
chdir = /var/www/servers/example/development/webapp
wsgi-file = /var/www/servers/example/development/webapp/webapp/wsgi.py
virtualenv = /var/www/servers/example/development/env
vacuum = true
env = DJANGO_SETTINGS_MODULE=webapp.settings
pidfile2 = /var/www/servers/example/development/logs/example.pid

uWSGI配置生產

[uwsgi]
master = true
workers = 2
socket = /var/www/servers/example/production/sockets/example.sock
chmod-socket = 666
log-date = true
uid = www-data
gid = www-data
chdir = /var/www/servers/example/production/webapp
wsgi-file = /var/www/servers/example/production/webapp/webapp/wsgi.py
virtualenv = /var/www/servers/example/production/env
vacuum = true
env = DJANGO_SETTINGS_MODULE=webapp.settings
pidfile2 = /var/www/servers/example/production/logs/example.pid

Answer 1

盡管您以root用戶身份運行服務器，但它會將特權降低到33（大概是www-data）。 該用戶（33）必須擁有刪除/var/www/servers/examples/production/sockets/example.sock的權限。

崩潰很可能損壞了現在具有錯誤屬性的inode。 修復它們，它應該可以再次工作。