Could not start uwsgi process

问题:

Could not start uwsgi process via ini flag

uwsgi --ini file.ini

No any uwsgi pids

ps aux | grep uwsgi
root     31605  0.0  0.3   5732   768 pts/0    S+   06:46   0:00 grep uwsgi

file.ini

[uwsgi]

chdir =/var/www/lvpp/site

wsgi-file =/var/www/lvpp/lvpp.wsgi

master = true

processes = 1

chmod-socket=664

socket = /var/www/lvpp/lvpp.sock

pidfile= /var/www/lvpp/lvpp.pid

daemonize =/var/www/lvpp/logs/lvpp.log

vacuum = true

uid = www

gid = www

env = DJANGO_SETTINGS_MODULE=settings

file lvpp.log

*** Starting uWSGI 2.0.10 (32bit) on [Wed Apr  8 06:46:15 2015] ***
compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-11) on 17 March   2015 21:29:09
os: Linux-2.6.32-431.29.2.el6.i686 #1 SMP Tue Sep 9 20:14:52 UTC 2014
machine: i686
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /var/www/lvpp
writing pidfile to /var/www/lvpp/lvpp.pid
detected binary path: /var/www/lvpp/site/env/bin/uwsgi
setgid() to 503
setuid() to 501
chdir() to /var/www/lvpp/site/
your processes number limit is 1812
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
error removing unix socket, unlink(): Permission denied [core/socket.c  line 198]
bind(): Address already in use [core/socket.c line 230]

It worked early. But when I invoked kill -9 uwsgi.pid I could not start uwsgi process again.

Please tell me, why can I start uwsgi process again? Thanks

回答1:

The key is: error removing unix socket, unlink(): Permission denied [core/socket.c line 198]

You (very probably) previously run a uwsgi instance as root creating the unix socket file with root permissions.

Now your instance (running instead as www) is not able to re-bind() that socket as it is not able to unlink it (no permissions)

Just remove the socket file and retry.

回答2:

I was running into a very similar issue, except it still wouldn't work even after deleting the socket file. Turns out it was because uWSGI couldn't create a new one (it only existed because I ran uwsgi myself). The infuriatingly simple solution was to chmod the directory containing the socket file, allowing the www user to create and modify files there. Obvious now, but maybe this will help a future poor sap bashing their head against a wall, as I have been for too many hours today.

root@srv16:/var/run/uwsgi> ls -la
total 0
drwxr-xr-x  2 root    root      60 Jul 16 07:11 .          #<-- problem
drwxr-xr-x 25 root    root     880 Jul 19 09:14 ..
srw-rw----  1 www-app www-data   0 Jul 16 07:11 app.socket 
               #^-- no idea how www-app managed to create that file

root@simsrv16:/var/run/uwsgi> chmod 777 .                  #<-- fix