Can only run uwsgi with root

Question

I'm preparing to use nginx/uwsgi with flask for a website i'm developing, but i'm running into problems. NB the website itself runs great using flask's debug :5000 port, but i want to go into production now. To explain what i did.

It's a linode ubuntu 12.04LTS server, I installed it like this:

# install nginx
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:nginx/stable
sudo apt-get update
sudo apt-get upgrade --show-upgraded
sudo apt-get install nginx-full
# installing uwsgi
sudo apt-get install build-essential python-dev libxml2-dev
sudo apt-get install libc6 libexpat1 libgd2-xpm libgeoip1 libpam0g libpcre3 libssl1.0.0 libxml2 libxslt1.1 zlib1g 
sudo pip install uwsgi
# python basics
sudo apt-get install python-pip build-essential python-dev
sudo pip install virtualenv
sudo pip install virtualenvwrapper
sudo mkdir -p /srv/www/li/
cd /srv/www/li/
virtualenv venv
source /srv/www/li/venv/bin/activate
pip install flask

Then i set out to configure everything, but I already run into trouble with uwsgi (never mind NGINX, which will be the next step.

sudo nano /etc/uwsgi/apps-available/li.xml

    <uwsgi> 
    <plugin>python</plugin> 
    <socket>/run/uwsgi/app/li.socket</socket>
    <chmod-socket>666</chmod-socket>
    <chdir>/srv/www/li</chdir>
    <pythonpath>/srv/www/li</pythonpath>
    <virtualenv>/srv/www/li/venv</virtualenv>
    <module>li</module>
    <wsgi-file>/srv/www/li/li.py</wsgi-file>
    <callable>app</callable> 
    <master/> 
    <processes>4</processes> 
    <harakiri>60</harakiri> 
    <reload-mercy>8</reload-mercy> 
    <cpu-affinity>1</cpu-affinity> 
    <stats>/tmp/stats.socket</stats> 
    <max-requests>2000</max-requests> 
    <limit-as>512</limit-as> 
    <reload-on-as>256</reload-on-as> 
    <reload-on-rss>192</reload-on-rss> 
    <no-orphans/> 
    <vacuum/> 
</uwsgi>

sudo ln -s /etc/uwsgi/apps-available/li.xml /etc/uwsgi/apps-enabled/li.xml

However if i run it, i get:

uwsgi --xml /etc/uwsgi/apps-enabled/li.xml

[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml
open("./python_plugin.so"): No such file or directory [core/utils.c line 4755]
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!!
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 16:30:53 2013] ***
compiled with version: 4.6.3 on 28 February 2013 12:38:22
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013
nodename: demo
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /run/uwsgi/app
detected binary path: /usr/local/bin/uwsgi
your processes number limit is 63594
limiting address space of processes...
your process address space limit is 536870912 bytes (512 MB)
your memory page size is 4096 bytes
 *** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /run/uwsgi/app/li.socket fd 3
Python version: 2.7.3 (default, Aug  1 2012, 05:25:23)  [GCC 4.6.3]
Set PythonHome to /srv/www/li/venv
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0xa86e20
your server socket listen backlog is limited to 100 connections
mapped 362120 bytes (353 KB) for 4 cores
*** Operational MODE: preforking ***
added /srv/www/li/ to pythonpath.
/srv/www/li/venv/local/lib/python2.7/site-packages/mongoengine/fields.py:744: FutureWarning: ReferenceFields will default to using ObjectId  strings in 0.8, set DBRef=True if this isn't desired
  warnings.warn(msg, FutureWarning)
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xa86e20 pid: 14934 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 14934)
spawned uWSGI worker 1 (pid: 14940, cores: 1)
mapping worker 1 to CPUs: 0
spawned uWSGI worker 2 (pid: 14941, cores: 1)
mapping worker 2 to CPUs: 1
spawned uWSGI worker 3 (pid: 14942, cores: 1)
mapping worker 3 to CPUs: 2
spawned uWSGI worker 4 (pid: 14943, cores: 1)
unlink(): Operation not permitted [core/socket.c line 109]
bind(): Address already in use [core/socket.c line 141]
...brutally killing workers...
mapping worker 4 to CPUs: 3
VACUUM: unix socket /run/uwsgi/app/li.socket removed.

So i get the unlink operation not permitted and the bind address already in use errors (next to the python_plugin error of which i also have no clue how to solve that!). If i run as sudo, it seems to work fine ->

sudo uwsgi --xml /etc/uwsgi/apps-enabled/li.xml

[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml
open("./python_plugin.so"): No such file or directory [core/utils.c line 4755]
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!!
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 15:47:41 2013] ***
compiled with version: 4.6.3 on 28 February 2013 12:38:22
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013
nodename: demo
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /run/uwsgi
detected binary path: /usr/local/bin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** 
your processes number limit is 63594
limiting address space of processes...
your process address space limit is 536870912 bytes (512 MB)
your memory page size is 4096 bytes
 *** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /run/uwsgi/app/li.socket fd 3
Python version: 2.7.3 (default, Aug  1 2012, 05:25:23)  [GCC 4.6.3]
Set PythonHome to /srv/www/li/venv
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1fc9d00
your server socket listen backlog is limited to 100 connections
mapped 362120 bytes (353 KB) for 4 cores
*** Operational MODE: preforking ***
added /srv/www/li/ to pythonpath.
/srv/www/li/venv/local/lib/python2.7/site-packages/mongoengine/fields.py:744: FutureWarning: ReferenceFields will default to using ObjectId  strings in 0.8, set DBRef=True if this isn't desired
  warnings.warn(msg, FutureWarning)
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1fc9d00 pid: 14755 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 14755)
spawned uWSGI worker 1 (pid: 14761, cores: 1)
mapping worker 1 to CPUs: 0
spawned uWSGI worker 2 (pid: 14762, cores: 1)
mapping worker 2 to CPUs: 1
spawned uWSGI worker 3 (pid: 14763, cores: 1)
mapping worker 3 to CPUs: 2
spawned uWSGI worker 4 (pid: 14764, cores: 1)
*** Stats server enabled on /tmp/stats.socket fd: 16 ***
mapping worker 4 to CPUs: 3

Can anyone please help me? As www-data is in the www-data group and he runs it, I tried some stuff:

sudo usermod -a -G www-data $USER
sudo chown -R $USER:www-data /srv/www/li
sudo chmod -R g+r+w+x /srv/www/li
sudo chown -R $USER:www-data /etc/uwsgi/apps-enabled
sudo chmod -R g+r+w+x /etc/uwsgi/apps-enabled
sudo chown -R $USER:www-data /run/uwsgi/app
sudo chmod -R g+r+w+x /run/uwsgi/app

But that really didn't help either. I also tried a tcp port instead of the unix /run/uwsgi/app/ port that didn't make any difference either... This is driving me crazy :( I hope someone has a clue on what's happening here.

Kind regards,

Carst

edit: after a server restart it still gives an erro but a different one:

geoadmin@demo:~$ uwsgi --xml /etc/uwsgi/apps-enabled/li.xml
[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 18:47:36 2013] ***
compiled with version: 4.6.3 on 28 February 2013 12:38:22
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013
nodename: demo
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /home/geoadmin
detected binary path: /usr/local/bin/uwsgi
your processes number limit is 63594
limiting address space of processes...
your process address space limit is 536870912 bytes (512 MB)
your memory page size is 4096 bytes
 *** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
bind(): No such file or directory [core/socket.c line 141]

Solution 1

Ok, after the later edit i checked the directories and the socket directory didnt exist (anymore); i think it had to do with the original apt-get install versus my later pip install... still have the issue with the python plugin but will check if it's necessary for nginx or if it will work without it... 8 hours of work over a reset, d'oh ;)

@bearrito: In the end I put the socket in the tmp directory to avoid rights issues:

<uwsgi>
        <uid>www-data</uid>
        <gid>www-data</gid> 
    <plugin>python</plugin> 
    <socket>/tmp/li.socket</socket>
    <chmod-socket>666</chmod-socket>
    <chdir>/srv/www/li</chdir>
    <pythonpath>/srv/www/li</pythonpath>
    <virtualenv>/srv/www/li/venv</virtualenv>
    <module>li</module>
    <wsgi-file>/srv/www/li/li.py</wsgi-file>
    <callable>app</callable> 
    <master/> 
    <processes>2</processes> 
    <pidfile>/tmp/li.pid</pidfile> 
    <harakiri>120</harakiri> 
    <reload-mercy>8</reload-mercy> 
    <cpu-affinity>1</cpu-affinity> 
    <stats>/tmp/stats.socket</stats> 
    <max-requests>2000</max-requests> 
    <limit-as>2048</limit-as> 
    <reload-on-as>2048</reload-on-as> 
    <reload-on-rss>1024</reload-on-rss> 
    <no-orphans/> 
    <vacuum/> 
</uwsgi>

I hope this helps!

Solution 2

This was consistently my #1 result on google, and this page was relatively unhelpful to me, so I'm going to add my answer, even though it's fairly obvious in retrospect.

My problem was a permissions problem with my stats socket. If you change your uWSGI config's uid or gid parameters, make sure you either chmod or rm all of your old sockets/ pids, and their parent folders.

Solution 3

In my case I was trying to place the .sock file in the /vagrant directory, which is a machine mounted folder of virtual box and is not good for much more than reads and writes.

Place the .sock file outside of a virtualbox mount-point preferably in /tmp The FHS says: /var/run

Ref: https://stackoverflow.com/a/7580524/1695680

Comments

[Carst]

Small later comment: the python plugin (which is in every googled example) doesn't seem to be necessary anymore in newer versions. So in the end it really does work easier and out of the box than I thought before!

[bearrito]

Can you bit a more explicit in what your fix entailed? I'm in the exact same scenario but I wasn't able to decipher something reproducible in my case.

[Carst]

Edited it with what i did! Also: my worker memory limits are really, so don't copy that :) (has to do with a heavy analytics process)

[Carst]

Hi, sorry to hear it didn't help you. it's what I mean with my "In the end I put the socket in the tmp directory to avoid rights issues" remark but you're right that it could have been a bit less cryptical. the problem was also caused by the fact that i had two issues at the same time, the other one being: stackoverflow.com/questions/15936413/…

[pnovotnak]

Sorry, didn't mean to attack your answer, only add to it for the next time I end up on this page. IMHO, the log messages from uWSGI are totally unhelpful in dealing with this issue.

[Carst]

Don't worry, didn't see it like that. I will edit the answer to help people better. Basically the issue is that you can have two separate problems at the same time (python plugin issue + rights socket issue) which also gave me a headache and is the reason why the original answer above is so broad

[Cherif KAOUA]

I got problems when putting the socket in tmp directory under fedora 20, saving file uploads tells permission denied , i think execution from /tmp/ have restricted access

[cjauvin]

This was really useful to me.

[mehmet]

adding an answer implies others were relatively unhelpful :)