I am trying to run nginx and uwsgi.
When I try to run uwsgi with below command in my proj virtual environment with proj user I get an error. When I run uwsgi, I see the proj.sock is created in /run/uwsgi/proj.sock
I changed the /run/uwsgi permissions to drwxrwxrwx to see if the problem is permission related. But problem still appears. I also checked the /etc/passwd and there is no uwsgi user.
The directory info for /run/uwsgi is :
drwxrwxrwx 2 root root 60 Jul 16 10:53 uwsgi
When I try to change ownership of sock file with proj user to proj:nginx in proj virtual nvironment I get the error below.
chown: changing ownership of ‘/run/uwsgi/proj.sock’: Operation not permitted
When I check /run/uwsgi/proj.sock file it is proj:proj but it should be changed to proj:nginx. This operation can be done manually with root. But it cannot be done with proj user.
Run below command:
uwsgi --ini /etc/uwsgi/sites/proj.ini
Error :
[uWSGI] getting INI configuration from /etc/uwsgi/sites/proj.ini<br>
*** Starting uWSGI 2.0.15 (64bit) on [Mon Jul 16 10:53:02 2018] ***<br>
compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-28) on 13 July 2018 17:12:50<br>
os: Linux-3.10.0-862.6.3.el7.x86_64 #1 SMP Tue Jun 26 16:32:21 UTC 2018<br>
nodename: localhost.localdomain<br>
machine: x86_64<br>
clock source: unix<br>
detected number of CPU cores: 2<br>
current working directory: /home/proj<br>
detected binary path: /home/proj/Env/proj/bin/uwsgi<br>
!!! no internal routing support, rebuild with pcre support !!!<br>
chdir() to /home/proj/work/proj<br>
your processes number limit is 4096<br>
your memory page size is 4096 bytes<br>
detected max file descriptor number: 1024<br>
lock engine: pthread robust mutexes<br>
thunder lock: disabled (you can enable it with --thunder-lock)<br>
chown(): Operation not permitted [core/utils.c line 2623]<br>
VACUUM WARNING: unix socket /run/uwsgi/proj.sock changed inode. Skip removal
My proj.ini file for uwsgi ini configuration is :
[uwsgi]
py-autoreload = 2
project = proj
username = proj
base = /home/%(username)
chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application
master = true
processes = %k
uid = %(username)
socket = /run/uwsgi/%(project).sock
chown-socket = %(username):nginx
chmod-socket = 666
vacuum = true
#logto = /var/log/uwsgi/%(project).log
A user can only set the group of a file to a group he is in. In this case your user proj is not in the nginx group, so it is not allowed to make that change. If you add the user to the nginx group (and relogin) then it should work.
Also, setting the directory permissions to 777 allows any user to create and delete files in that directory, and 666 for the socket allows any user to access it. You probably don't want that. More reasonable would be to have /run/uwsgi owned by root:nginx with mode 770, and chmod-socket = 660 in your project ini.
I solved the problem.
The socket files were in /run/uwsgi directory.
I gave the related project user right to write read execute on this folder.
setfacl -m u:projuser:rwx /run/uwsgi/
As suggested by "ivbtar", I just removed following lines from uwsgi.ini file and it started working,
chown-socket = %(username):nginx
chmod-socket = 666
Related
Following a bunch of tutorials, I wrote my first django app and then decided to deploy it on a linode server. Following their tutorial, I only got so far. The best I could tell, that was based on an earlier version of Ubunto and I tried some other things, including the uwsgi quickstart tutorial.
I got far enough that the command 'python manage.py runserver' would serve up my site and wanted to move on to using uwsgi to do the same.
It seems as though there is some environment variable missing. When I try to start uwsgi from the command line with:
uwsgi --http :8000 --module dynamicefl.wsgi
I get the following:
*** Starting uWSGI 2.0.15 (64bit) on [Fri Aug 11 19:37:04 2017] ***
compiled with version: 6.3.0 20170406 on 10 August 2017 23:41:13
os: Linux-4.9.36-x86_64-linode85 #1 SMP Thu Jul 6 15:31:23 UTC 2017
nodename: roosevelt
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/django/worksheets/dynamic-efl
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 3941
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)
uWSGI http bound on :8000 fd 4
spawned uWSGI http 1 (pid: 5998)
uwsgi socket 0 bound to TCP address 127.0.0.1:43637 (port auto-assigned) fd 3
Python version: 2.7.13 (default, Jan 19 2017, 14:48:08) [GCC 6.3.0 20170118]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x562bdad6fda0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
Traceback (most recent call last):
File "./dynamicefl/wsgi.py", line 12, in <module>
from django.core.wsgi import get_wsgi_application
ImportError: No module named django.core.wsgi
unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 5997, cores: 1)
A lot of the tutorials emphasize putting the path to the virtual environment in the .ini file, and I did (double checking with 'env' that I had the virtual environment right.) Here is the .ini file I'm working with
[uwsgi]
home = /home/django/Env/worksheets
chdir = /home/django/worksheets/dynamic-efl/dynamicefl
module = dynamicefl.wsgi::application
uid = www-data
gid = www-data
socket = localhost:9191
chmod-socket = 644
chown-socket = www-data
processes = 4
threads = 2
logto = /var/log/uwsgi.log
I have experimented with changing the chdir command some, as I'm not sure exactly where it should be pointing, but regarless of where it points that results in a similar line in uwsgi.log:
-- no python application found, check your startup logs for errors ---
(Fun fact: I haven't been able to find reference to uwsgi startup logs)
If I go to the site in my web browser, I get an 'Internal Server Error' message.
I don't think that anything is getting as far an nginx, but I can include the .conf file and error logs, too, if that's helpful.
I know that there are a log of similar questions, but I've looked at them and they're not helping me. (Which is not to say that they don't contain the answer.)
The django docs helped me out here. It turns out that my reference to the module was apparently wrong. I had a colon too many in the reference to the module. The corrected .ini reads:
module = dynamicefl.wsgi:application
What helped was resolving to battle it out until I could serve the site purely from uwsgi, so that I could stop restarting services.
I am trying to run this code
uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data
I am following this tutorial. But I am getting the below output.
*** Starting uWSGI 2.0.11.2 (64bit) on [Thu Nov 5 04:42:12 2015] ***
compiled with version: 4.8.4 on 04 November 2015 16:32:43
os: Linux-3.16.0-52-generic #71~14.04.1-Ubuntu SMP Fri Oct 23 17:24:53 UTC 2015
nodename: myproject
machine: x86_64
clock source: unix
detected number of CPU cores: 2
current working directory: /var/www/myproject
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
setgid() to 33
setuid() to 33
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 15305
your memory page size is 4096 bytes
detected max file descriptor number: 1024
*** starting uWSGI Emperor ***
This is my .ini file
plugins = python
chdir = /var/www/myproject/
module = myproject.wsgi:application
home = /var/www/
master = true
processes = 10
socket = /var/www/myproject/uwsgi.sock
chmod-socket = 666
vacuum = true
My code is working with this
uwsgi --ini myproject.ini
Please help me to solve this puzzle thank you.
It seems to work fine! Did you try connecting nginx? You can ignore the warnings now.
I'm not able to run uwsgi with upstart/supervisord, I used pyenv to setup python with virtualenv myenv, myenv has python3.4.3 and system's python pointing to python2.7.6. I changed pyenv global to 3.4.3.
Right now as my_user, which python => /home/my_user/.pyenv/shims/python and python --version => Python 3.4.3.
When I do with sudo, I get sudo which python => /usr/bin/python and sudo python --version => Python 2.7.6.
/etc/init/uwsgi_servers.conf has
description "uWSGI instance to serve authservice in production"
start on runlevel [2345]
stop on runlevel [!2345]
exec /usr/local/bin/uwsgi --emperor /etc/uwsgi/sites/ --uid my_user --gid my_user
and /etc/uwsgi/sites/uwsgi.ini has
[uwsgi]
# variables
projectname = accounts
base = /home/my_user/django/accounts/
for-readline = /home/my_user/conf/django/accounts/env_var
env = %(_)
endfor =
# config
chdir = /home/my_user/django/accounts/
master = True
processes = 5
protocol = uwsgi
env = in_accounts.settings.production
module = in_accounts.wsgi
socket = /tmp/uwsgi_%(projectname).sock
chmod-socket = 666
home = /home/my_user/.virtualenvs/accounts_production
logto = %(base)/logs/uwsgi.log
daemonize = /var/log/uwsgi/%(projectname).log
vacuum = True
pidfile = /tmp/%(projectname).pid
die-on-term = true
When I run sudo service uwsgi_servers start, I get error from log
*** Starting uWSGI 2.0.11.2 (64bit) on [Tue Oct 13 09:32:18 2015] ***
compiled with version: 4.8.4 on 12 October 2015 11:59:31
os: Linux-3.16.0-43-generic #58~14.04.1-Ubuntu SMP Mon Jun 22 10:21:20 UTC 2015
nodename: st-auths-web1
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/sites
writing pidfile to /tmp/accounts.pid
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
chdir() to /home/my_user/django/accounts/current
your processes number limit is 13731
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)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi_accounts.sock fd 3
Python version: 2.7.6 (default, Jun 22 2015, 18:01:27) [GCC 4.8.2]
Set PythonHome to /home/my_user/.virtualenvs/accounts_production
ImportError: No module named site
VACUUM: pidfile removed.
VACUUM: unix socket /tmp/uwsgi_accounts.sock removed.
From log I can see that starting uwsgi using upstart try to use python2.7.6 since I use sudo to run upstart service, but It should have used python3.4.3, this might be the reason why server isn't running. Though I use uid and gid I get the above error. I also tried setuid and setgid, but no luck.
NOTE: I can able to run uwsgi server successfully without upstart as uwsgi --emperor /etc/uwsgi/sites/. I tried use supervisord, but no use, getting same error.
To make this work you will have to tell wsgi which virtualenv to use that's with the -H option. If your virtualenv is in your home folder, upstart will not be able to access it. So move it to a readable place and try
uwsgi -H /usr/local/virtualenv
or something like that with the correct path to the virtualenv in your upstart file.
I'm trying to run a Flask application using a ubuntu 12.04 server with nginx and uWSGI however after starting the server, specifying the wsgi.ini file and then starting nginx, I try to access the page but I get a 502 bad gateway error with nginx. I know that it is an issue with the flask application and uWSGI. I checked the uWSGI logs and found this:
*** Starting uWSGI 2.0.11.1 (64bit) on [Thu Sep 17 19:38:03 2015] ***
compiled with version: 4.8.4 on 17 September 2015 15:58:04
os: Linux-3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015
nodename: ip-172-31-30-153
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/ubuntu/myapp
writing pidfile to /home/ubuntu/myapp/myapp.pid
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 7862
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)
uwsgi socket 0 bound to TCP address 127.0.0.1:5000 fd 3
Python version: 2.7.6 (default, Jun 22 2015, 18:01:27) [GCC 4.8.2]
Set PythonHome to /home/ubuntu/myapp
ImportError: No module named site
I found this question's top answer but saw received the same error. If it is something to do with PYTHONHOME, I'm following this guide and it states:
The $PYTHONPATH variable seems to get unset randomly, and causes
errors for later steps. To avoid this, add the following line to the
top of your ~/.bashrc file:
export
PYTHONPATH='/usr/lib/python2.7:/usr/lib/python2.7/plat-x86_64-linux-gnu:/usr/lib/python2.7/lib-tk:/usr/lib/python2.7/lib-old:/usr/lib/python2.7/lib-dynload:/usr/local/lib/python2.7/dist-packages:/usr/lib/python2.7/dist-packages:/usr/lib/python2.7/dist-packages/PILcompat'
So what could be the issue? Is it PYTHONHOME or another factor affecting it? Thanks.
Edit:
My uwsgi.ini:
[uwsgi]
home = /home/ubuntu/myapp
wsgi-file = %(home)/run.py
socket = 127.0.0.1:5000
callable = app
module = app
pythonpath = %(home)
daemonize = %(home)/myapp.log
pidfile = %(home)/myapp.pid
To run it, I use uwsgi uwsgi.ini.
Could not start uwsgi process via ini flag
uwsgi --ini file.ini
Not 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.
Why can't I start uwsgi process again?
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.
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
Beyond the main socket there could be also a stats socket. :)
The error log actually could be more specific abouth the path that isn't mentioned.